NCS  TIB  93-13 


NATIONAL  COMMUNICATIONS  SYSTEM 


TECHNICAL  INFORMATION  BULLETIN  93-13 


TRANSPORTING  VIDEO 
TELECONFERENCING  TRAFFIC 


DECEMBER  1993 


OFFICE  OF  THE  MANAGER 

NATIONAL  COMMUNICATIONS  SYSTEM 
701  SOUTH  COURT  HOUSE  ROAD 
ARLINGTON,  VA  22204-2198 


19970117  046 


THIS  DOCUMENT  IS  BEST 
QUALITY  AVAILABLE.  THE  COPY 
FURNISHED  TO  DTIC  CONTAINED 
A  SIGNIFICANT  NUMBER  OF 
PAGES  WHICH  DO  NOT 
REPRODUCE  LEGIBLY 


REPORT  DOCUrVlErxSTATION  PAGE 


Form  Approved 
0MB  No.  0704^0788 


’pubTic  reporting  burden  for  this  collection  of  information  is  estimated  to  average  l  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  colleaion  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson 
Davis  Highway  Suite  1204  Arlington.  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503. 


i.  AGEFv^CY  USE  OTx'LY  (Leave  blank)  2.  REPORT  DATE 

December  1993 


I  4.  TiTLE  AND  SUBTITLE 

I  Transporting  Video  Teleconferencing  Traffic 


3,  REPORT  TYPE  Af^D  DATES  COVERED 

Final  Report  _ _ 


5.  FUMDIF^G  NUMBERS 
DCA100-91-C-0031 


6.  AUTHOR(S) 

Stephen  Perschau 


PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Delta  Information  Systems,  Inc. 

300  Welsh  Road,  Building  #3,  Suite  120 
Horsham,  PA  19044-2273 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


9.  SPONSORING /MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

National  Communications  System 

Office  of  Technology  and  Standards  Division 

701  South  Court  House  Road 

Arlington,  Virginia  22204-2198 


10.  SPONSORING/MONJTORING 
AGENCY  REPORT  NUMBER 

NCS  TIB  #93-13 


11.  SUPPLEMENTARY  NOTES 


IZaT  DISTRIBOTION  /  AVAILABILITY  STATEMENT 


Approved  for  public  release;  distribution  is  unlimited. 


12b.  DISTRIBUTION  CODE 


r  13.  ABSTRACT  (Maximum  200  words) 

The  purpose  of  this  document  is  to  summarize  the  work  accomplished  on  Subtask  4 
(Transporting  Video  Teleconferencing  Traffic)  of  Task  2  (Technical  Work  in  the  Area 
of  Videoconferencing)  of  this  contract.  The  purpose  of  this  subtask  was  to  study 
alternative  media  for  transporting  video  teleconferencing  traffic.  In  the  first 
step  of  the  project  basic  transport  media  (as  opposed  to  Alternative  Media)  which 
are  commonly  used  for  video  conferencing  were  reviewed.  This  analysis  provides 
reference  for  the  discussion  of  the  non-traditional  telecommunication  techniques. 
Four  alternative  transport  media  were  examined:  LANs/MANs,  PSTN,  mobile  radio,  and 
Internet.  Each  of  these  media  is  reviewed  and  analyzed  in  a  separate  section  of  the 
report.  The  status  of  the  technology  for  each  medium  is  reviewed  including  a  review 
of  the  standardization  status.  Commercial  products,  if  any,  are  identified  and 
classified.  Finally  the  applications  and  implications  of  the  medium  to  provide 
video  telephony  services  in  the  Government  community  are  reviewed.  Overall 
I  conclusions  and  recommendations  are  included. 


subTect  terms 

Video  Teleconferencing  Traffic 

15.  NUMBER  OF  PAGES 

150 

1  Mobile  Audio  Visual  Terminal  (MAVT) ,  Mobll« 
1  Fiber  Distributed  Data  Interface  (FDDI) 

5  Radio 

16.  PRICE  CODE 

iir  SECURlfV  CLASSIFiCATlOW 

OF  REPORT 

18. '  security  classification 

OF  this  page 

T9.“  security  CLAS^^^ 

OF  ABSTRACT 

20.  LIMITATION  OF  ABSTRACT 

UNCLASS 

UNCLASS 

UNCLASS 

UNLIMITED 

NSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89) 

Prescribed  by  ANSI  Std  Z39-18 
298-102 


GEiV'ERAL  ll\!STRUCTIO[^S  FOR  COMPLETIMG  SF  298 


The  Report  Documentation  Page  (RDP)  is  used  in  announcing  and  cataloging  reports.  It  is  important 
that  this  information  be  consistent  with  the  rest  of  the  report,  particularly  the  cover  and  title  page. 
Instructions  for  filling  in  each  block  of  the  form  follow'.  It  is  important  to  stay  within  the  iines  to  meet 

optica!  scanning  reguiremersts. 


Use  Only  (Leave  blank). 


Block  2.  Report  Date.  Full  publication  date 
including  day,  mionth,  and  year,  if  available  (e.g.  1 
Jan  88).  Must  cite  at  least  the  year. 

Block  3.  Type  of  Report  and  Dates  Covered. 
State  w'hether  report  is  interim,  final,  etc.  If 
applicable,  enter  inclusive  report  dates  (e.g.  10 
Jun87-30Jun8S). 

Elock4.  Title  and  Subtitle.  A  title  is  taken  from 
the  part  of  the  report  that  provides  the  most 
meaningful  and  complete  information.  When  a 
report  is  prepared  in  more  than  one  volume, 
repeat  the  primary  title,  add  volume  number,  and 
include  subtitle  for  the  specific  volume.  On 
classified  documents  enter  the  title  classification 
in  parentheses. 

Blocks.  Funding  Numbers.  To  include  contract 
and  grant  numbers;  may  include  program 
element  numberfs),  project  number(s),  task 
number(s),  and  work  unit  number(s).  Use  the 
following  labels; 


Contract 

PR  - 

Project 

Grant 

TA  - 

Task 

Program 

WU  - 

Work  Unit 

Element 

Accession  No 

Blocks.  Author(s).  Namefs)  of  person(s) 
responsible  for  w'riting  the  report,  performing 
the  research,  or  credited  with  the  content  of  the 
report.  If  editor  or  compiler,  this  should  follow' 
the  name{s). 

Block?.  Performing  Organization  Name(s)  and 
Address(es).  Self-explanatory. 

Block  8.  Performing  Organization  Report 
Number.  Enterthe  unique  alphanumeric  report 
number(s)  assigned  by  the  organization 
performing  the  report. 

Blocks.  Sponsor! ng/Monitorinq Agency  Name(s) 
and  Address(es).  Self-explanatory. 

Block  10.  Sponsoring/Monitorinq  Agency 
Report  Number.  (If  known) 

Block  11.  Supplementary  Notes.  Enter 
information  not  included  elsewhere  such  as: 
Prepared  in  cooperation  with...;  Trans,  of...;  To  be 
published  in....  When  a  report  is  revised,  include 
a  statement  whether  the  new'  report  supersedes 
or  supplements  the  older  report. 


Block  12a.  Distribution/Availabilitv  Statement. 
Denotes  public  availability  or  limitations.  Cite  any 
availability  to  the  public.  Enter  additional 
limitations  or  special  markings  in  all  capitals  (e.g. 
NOFORN,  REL,  ITAR). 

DOD  -  See  DoDD  5230.24,  "Distribution 
Statements  on  Technical 
Documents." 

DOE  -  See  authorities. 

NASA  -  See  Handbook  NHB  2200.2. 

NTiS  -  Leave  blank. 


Block  12b.  Distribution  Code. 


Leave  blank. 

Enter  DOE  distribution  categories 
from  the  Standard  Distribution  for 
Unclassified  Scientific  and  Technical 
Reports. 

Leave  blank. 

Leave  blank. 


NASA 

NTiS 


Block  13.  Abstract.  Include  a  brief  (Max/mum 
200  words)  factual  summary  of  the  most 
significant  information  contained  in  the  report. 

Block  14.  Subject  Terms.  Keywords  or  phrases 
identifying  major  subjects  in  the  report. 

Block  15.  Number  of  Pages.  Enterthe  total 
number  of  pages. 

Block  16.  Price  Code.  Enter  appropriate  price 
code  (NTIS  only). 

Blocks  17.  - 19.  Security  Classifications.  Self- 
explanatory.  Enter  U.S.  Security  Classification  in 
accordance  with  U.S.  Security  Regulations  (i.e., 
UNCLASSIFIED).  If  form  contains  classified 
information,  stamp  classification  on  the  top  and 
bottom  of  the  page. 

Block  20.  Limitation  of  Abstract.  This  block  must 
be  completed  to  assign  a  limitation  to  the 
abstract.  Enter  either  UL  (unlimited)  or  SAR  (same 
as  report).  An  entry  in  this  block  is  necessary  if 
the  abstract  is  to  be  limited.  If  blank,  the  abstract 
is  assumed  to  be  unlimited. 


Standard  Form  298  Back  (Rev.  2-89) 


TASK  NO.  2 

TECHNICAL  WORK  IN  THE  AREA 
OF  VIDEO  TELECONFERENCING 

SUBTASK  4 

TRANSPORTING  VIDEO 
TELECONFERENCING  TRAFFIC 


FINAL  REPORT 

CONTRACT  DCA1 00-91 -C-0031 


Submitted  to: 

NATIONAL  COMMUNICATIONS  SYSTEM 
WASHINGTON,  DC 


November  1,  1993 


DELTA  INFORMATION  SYSTEMS,  INC. 
300  Welsh  Road,  Bldg.  3,  Ste.  120 
Horsham,  PA  19044-2273 

TEL:  (215)657-5270  FAX:  (215)657-5273 


NCS  TECHNICAL  INFORMATION  BULLETIN  93-13 
TRANSPORTING  VIDEO  TELECONFERENCING  TRAFFIC 
DECEMBER  1993 


PROJECT  OFFICER.  .  /' 


GARY  REKSTAD 
Electronics  Engineer 
Office  of  Technology 
and  Standards 


APPROVED  FOR  PUBLICATION: 


DENNIS  BODSON 
Assistant  Manager 
Office  of  Technology 
and  Standards 


FOREWORD 


Among  the  responsibilities  assigned  to  the  Office  of  the  Manager, 
National  Communications  System,  is  the  management  of  the  Federal 
Telecommunication  Standards  Program.  Under  this  program,  the  NCS,  with  the 
assistance  of  the  Federal  Telecommunication  Standards  Committee  identifies, 
develops,  and  coordinates  proposed  Federal  Standards  which  either  contribute 
to  the  interoperability  of  functionally  similar  Federal  telecommunication 
systems  or  to  the  achievement  of  a  compatible  and  efficient  interface  between 
computer  and  telecommunication  systems.  In  developing  and  coordinating  these 
standards,  a  considerable  amount  of  effort  is  expended  in  initiating  and 
pursuing  joint  standards  development  efforts  with  appropriate  technical 
committees  of  the  International  Organization  for  Standardization,  and  the 
International  Telegraph  and  Telephone  Consultative  Committee  of  the 
International  Telecommunication  Union.  This  Technical  Information  Bulletin 
presents  an  overview  of  an  effort  which  is  contributing  to  the  development  of 
compatible  Federal,  national,  and  international  standards  in  the  area  of  Video 
Teleconferencing.  It  has  been  prepared  to  inform  interested  Federal 
activities  of  the  progress  of  these  efforts.  Any  comments,  inputs  or 
statements  of  requirements  which  could  assist  in  the  advancement  of  this  work 
are  welcome  and  should  be  addressed  to: 


Office  of  the  Manager 
National  Communications  System 
Attn:  NT 

701  S.  Court  House  Road 
Arlington,  VA  22204-2198 
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1.0  INTRODUCTION 


The  National  Communications  System  has  awarded  Contract  DCA  1 00-91 -C- 
0031  entitled  "System  Engineering  and  Technical  Assistance  in  the  Area  of 
Facsimile  and  Video  Teleconferencing  for  the  Office  of  the  Manager",  to  Delta 
Information  Systems.  The  purpose  of  this  document  is  to  summarize  the  work 
accomplished  on  Subtask  4  (Transporting  Video  Teleconferencing  Traffic)  of  Task  2 
(Technical  Work  In  the  Area  of  Videoconferencing)  of  this  contract. 

The  purpose  of  this  subtask  was  to  study  alternative  media  for  transporting 
video  teleconferencing  traffic.  In  the  first  step  of  the  project  basic  transport  media 
(as  opposed  to  Alternative  Media)  which  are  commonly  used  for  video  conferencing 
were  reviewed.  This  analysis,  contained  in  section  2.0  provides  reference  for  the 
discussion  of  the  non-traditional  telecommunication  techniques. 

Four  alternative  transport  media  were  examined:  LANs/MANs,  PSTN,  mobile 
radio,  and  Internet.  Each  of  these  media  is  reviewed  and  analyzed  in  a  separate 
section  of  the  report.  The  status  of  the  technology  for  each  medium  is  reviewed 
including  a  review  of  the  standardization  status.  Commercial  products,  if  any,  are 
identified  and  classified.  Finally  the  applications  and  implications  of  the  medium  to 
provide  video  telephony  services  in  the  Government  community  are  reviewed. 

Overaii  conclusions  and  recommendations  are  included  in  Section  7.0. 
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2.0  BASIC  TRANSPORT  MEDIA  FOR  VIDEO  TELECONFERENCING 

In  general,  video  teleconferencing  requires  a  high  transmission  bit  rate 
relative  to  other  services  such  as  voice  and  data.  For  that  reason,  the  availability 
of  teleconferencing  for  the  government  community  is  dependent  upon  the 
availability  of  ubiquitous,  inexpensive  communication  channels  operating  at  high  bit 
rates.  The  purpose  of  this  section  is  to  review  the  primary  telecommunication 
options  which  are  now  used  for  Video  Teleconferencing  (VTC)  today.  The 
discussion  is  divided  into  four  parts:  (1)  Non  -  ISDN  Media  (2)  narrow  band  ISDN, 

(3)  broadband  ISDN,  and  (4)  FTS-2000. 

2.1  Non  -  ISDN  Transport  Media  for  VTC 

Today’s  teleconferencing  user  has  a  range  of  choices  in  transmission, 
both  in  network  options  and  selection  of  data  rate.  Customarily,  teleconferencing 
transmission  rates  are  divided  into  two  general  categories  --  narrowband  (switched 
56  kbps  circuits)  and  wideband  (384  kbps,  768  kbps,  1.544  Mbps)  --  though  even 
this  distinction  has  blurred  somewhat  as  new  technologies  enable  the  delivery  of 
wideband  transmission  rates  through  aggregations  of  narrowband  circuits. 

Typically,  wideband  VTC  networks  are  implemented  either  through  dedicated 
private  T1  networks  or  virtual  private  networks  (both  available  from  all  major 
carriers),  or  through  the  use  of  carriers’  reservation-based  switched  wideband 
networks  (AT&T's  Accunet  Reserved,  Sprint’s  Meeting  Channel,  and  MCl’s 
VideoNet).  Transmission  rates  are  normally  384  kbps,  768  kbps,  or  1.5  Mbps.  It 
is  not  uncommon  for  a  user  to  maintain  a  private  network  for  internal 
videoconferencing  while  periodically  using  the  carriers'  switched  services  for 
communication  with  off-network  sites  -  particularly  international  connections. 

In  either  a  dedicated  or  switched  environment,  a  dedicated  T1  trunk  must  be 
brought  to  the  user’s  premises.  If  the  user  wants  to  retain  the  flexibility  of 
choosing  services  from  multiple  carriers,  then  the  access  line  will  be  routed  through 
the  local  telephone  company  central  office;  otherwise,  the  access  line  is  connected 
to  a  single  carrier’s  point  of  presence  for  use  either  in  a  dedicated  or  switched 
configuration. 

Narrowband  VTC  transmission  relies  on  switched-56  digital  service  offerings. 
Switched-56  network  services  became  accessible  to  VTC  users  in  1987,  when  two 
56  kbps  circuits  could  first  be  synchronized  for  a  total  data  rate  of  112  kbps.  A 
single  switched-56  circuit  is  generally  inadequate  for  video  teleconferencing,  but 
two  56  kbps  circuits  can  provide  enough  bandwidth  to  accommodate  the  16  kbps 
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or  32  kbps  that  must  be  assigned  to  audio  while  leaving  sufficient  capacity  for 
video  transmission. 

While  the  video  quality  is  obviously  reduced  relative  to  that  available  in 
wideband  videoconferencing,  many  companies  have  found  it  to  be  acceptable  for  a 
range  of  teleconferencing  applications.  These  companies  have  found  that  the 
trade-off  of  lost  picture  quality  is  compensated  for  by  the  inexpensive  transmission 
costs  for  56  kbps  dial-up  circuits.  In  1985,  the  cost  of  a  switched  56  kbps  line 
war  around  $75  per  hour;  today,  a  switched  domestic  conference  at  112  kbps  will 
cost  no  more  than  $26  per  hour  -  not  much  more  than  a  normal  long  distance 
phone  call. 

Additionally,  the  introduction  of  inverse  multiplexing  technology  into  the 
videoconferencing  market  has  radically  altered  users'  options  for  increased 
bandwidth.  Inverse  multiplexers  (l-muxes)  permit  wideband  videoconferences  to  be 
carried  on  switched-56  networks;  they  do  so  by  dividing  a  wideband  data  stream 
emanating  from  a  codec  into  multiple  individual  narrowband  streams  -  literally,  by 
performing  the  inverse  function  of  a  standard  multiplexer.  At  the  receiving  end,  an 
l-mux  accepts  the  multiple  narrowband  data  streams  and  synchronizes  them  into  a 
single  wideband  signal  for  receipt  and  processing  by  the  video  codec. 

An  inverse  multiplexer  enables  users  to  videoconference  over  dial-up  digital 
circuits  at  rates  up  to  1.344  Mbps  (24  x  56  kbps).  This  allows  users  to  retain  the 
flexibility  and  low  cost  of  dial-up  access  while  enabling  better  picture  quality 
through  higher  data  rates. 

If  users  only  employ  switched-1 12  services,  then  the  access  lines  are  56 
kbps  circuits.  Use  of  an  inverse  multiplexer  requires  users  to  lease  T1  access  to 
the  carrier's  point  of  presence.  (The  cost  of  T1  access  is  usually  equivalent  to  four 
56  kbps  circuits,  however,  so  it  is  often  easy  to  justify.)  After  access  charges,  the 
user  pays  only  for  the  actual  calls  placed  on  the  switched  network. 

The  Department  of  Defense  has  established  the  Defense  Communications 
Teleconference  Network  (DCTN)  to  provide  teleconference  services  within  that 
agency.  This  network  provides  switched  service  at  a  transmission  bit  rate  of 
1 .544  mbps.  Work  is  presently  underway  for  reducing  this  bit  rate  to  768  or  384 
Kbps. 
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2.2  Narrowband  ISDN 


Users  looking  for  improved  net'A^ork  performance  (i.e.  faster  call  set-up, 
better  connections  between  sites)  or  access  to  high-speed  switched  data  services 
may  use  ISDN  for  videoconferencing.  ISDN  (Integrated  Digital  Services  Network) 
refers  to  an  emerging  set  of  worldwide  standards  for  end-to-end  digital  information 
transfer.  It  is  endorsed  by  the  International  Telecommunications  Union  (ITU),  the 
American  National  Standards  Institute  (ANSI),  and  virtually  every  other  national 
telecommunications  authority.  Eventually,  ISDN  will  transform  the  present 
telephone  network  into  an  end-to-end  switched  digital  network  providing  variable 
transmission  rates  in  64-kbps  increments. 

A  primary  objective  of  ISDN  is  to  provide  a  variety  of  network  services 
through  a  standard  set  of  network  interfaces.  This  will  enable  users  in  most  cases 
to  access  voice,  data,  and  image  via  a  single  standard  network  connection.  A 
second  objective,  interoperability  of  switches  and  terminal  equipment,  will  be 
assured  by  conformance  to  standards.  Such  standardization  will  lead  to  significant 
reductions  in  equipment  costs;  ISDN  will  also  contribute  to  reduced  operating  costs 
through  its  capability  of  continuously  monitoring  loop  performance  over  the 
embedded  maintenance  channel. 

While  Japan  and  some  European  countries  have  deployed  ISDN  more 
extensively,  fewer  than  40%  of  U.S.  central  offices  are  currently  equipped  to 
handle  ISDN  traffic.  Growth  should  be  steady,  however;  the  Regional  Bell 
Operating  Companies  (RBOCs)  project  that  by  the  end  of  1994,  they  will  have 
almost  65  million  ISDN-capable  lines  (57%  of  all  lines)  and  1,832  ISDN-capable 
switches  (19%  of  all  switches).  Additionally,  each  of  the  seven  RBOCs  has  put 
ISDN  basic  rate  tariffs  in  place. 

The  Federal  Government  also  strongly  endorsed  ISDN  by  awarding  a  ten- 
year,  multibillion  dollar  contract  for  FTS-2000  to  A&T  and  Sprint.  Both  proposals 
were  based  on  ISDN  architecture. 

2.2.1  Basic  Rate  Interface  (BRI) 

The  Basic  Rate  Interface  (BRI)  is  comprised  of  two  64-kbps  data  channels, 
know  as  B  channels,  and  a  single  16-kbps  signaling  channel  known  as  the  D 
channel.  The  data  and  signaling  channels  are  time-division  multiplexed  into  a  single 
stream  to  provide  a  composite  full-duplex  bandwidth  of  144  kbps. 

BRI  provides  a  composite  bandwidth  of  144  kbps  (2  x  64  kbps  B  channels  -i- 
1x16  kbps  D  channel)  and  full  duplex  transmission  with  time  division  multiplexing 
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(TDM)  into  a  single  stream  containing  both  user  and  signalling  information. 

Basic  rate  ISDN  uses  existing  network  facilities,  typified  by  the  twisted  pair 
local  loop  and  64-kbps  digital  switch.  Basic  rate  service  (2B  +  D)  can  be  provided 
to  the  customer  by  replacing  and  analog  telephone  with  an  ISDN  telephone  and  a 
network  termination.  The  B  channels  (64  kbps)  provide  circuit-switched  voice  and 
data  and  packet-switched  data;  the  D  channel  (16  kbps)  provides  out-of-band 
signalling  plus  packet  data.  Basic  rate  ISDN  allows  applications  such  as  Group  IV 
facsimile,  PC  screen  sharing,  image  transfer  and  limited  motion  videophone. 
(Primary  rate  (2B-fD)  provides  up  to  1.536  Mbps.) 

All  seven  Regional  Bell  Operating  companies  have  filed  ISDN  Basic  Rate 
Interface  (BRI)  tariffs. 

As  inter-switch  SS7  connectivity  becomes  pervasive  and  equipment  for 
applications  becomes  less  expensive,  ISDN  will  become  more  acceptable  to  the 
small  user. 

2.2.2  Primary  Rate  Interface  (PRI) 

The  Primary  Rate  Interface  (PRI)  is  comprised  of  23  64-kbps  B  channels,  and 
one  64-kbps  D  channel  for  signaling,  for  a  composite  bandwidth  of  1.536  Mbps. 

(In  Europe,  the  ISDN  PRI  configuration  is  30B  +  D.) 

Under  the  PRI  standard,  certain  aggregations  of  B  channels  can  create  high¬ 
speed  H  channels.  Six  PRI  B  channels  define  an  HO  channel  at  384  kbps;  23  B 
channels  define  an  H10  channel  at  1.472  Mbps;  24  B  channels  define  an  H11 
channel  at  1.536  Mpbs.  These  wideband  H  channels  could  possible  be  used  to 
meet  most  demands  of  data  communications  users. 

Primary  rate  ISDN  (PRI)  consists  of  23  64-kbps  B  channels  (30B  channels  in 
Europe)  and  one  64-kbps  D  channel  for  signalling.  The  PRI  may  also  be  allocated 
as  high-speed  (H)  channels  at  384,  1472  or  1536  kbps.  The  H  channels  are 
currently  viewed  as  wideband  circuits  and  could  possibly  be  used  to  meet  most 
demands  of  data  communications  users. 

Primary  rate  channels  can  be  used  to  multiplex  lower  data  rate  channels, 
provide  high-data-rate  wide  area  network  connectivity  and  implement  private 
branch  exchange  (PBX)  connectivity. 

PRI  can  also  be  used  for  LAN-to-LAN  connectivity. 
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2.3  Broadband  ISDN 


The  Integrated  Services  Digital  Network  (ISDN)  is  divided  into  two  parts  — 
narrowband  and  broadband.  Narrowband  ISDN,  described  in  the  last  section, 
operates  at  rates  equal  to  or  less  than  the  primary  rates  (e.g.  1 .544  Mbps). 
Broadband  ISDN,  also  known  as  B-ISDN,  operates  at  transmission  speeds  above 
the  primary  rate.  B-ISDN  promises  to  allow  very  high  speed  digital  transmissions 
(155.52  Mbps,  622.08  Mbps,  2488.32  Mbps)  that  will  dwarf  the  N-ISDN. 

While  the  standards  for  N-ISDN  have  been  sufficiently  set  in  place  to  permit 
deployment  of  N-ISDN  networks  and  applications  today,  B-ISDN  is  not  yet  market- 
ready.  Because  B-ISDN  is  still  nascent,  this  section  necessarily  concentrates  on 
providing  an  update  of  relevant  standards  and  definitions  of  B-ISDN  rather  than 
describing  the  technology  in  terms  specific  to  videoconferencing. 

One  backbone  structure  for  the  B-ISDN  consists  of  a  new  Synchronous 
Digital  Hierarchy  (SDH)  defined  in  CCITT  Recommendations  G.707,  G.708,  and 
G.709'’^‘^’‘^’.  These  recommendations  are  concerned  with  bit  rates  for  the 
synchronous  digital  hierarchy,  details  of  the  resulting  network  node  interface,  and  a 
synchronous  network  multiplexing  structure.  Three  digital  Synchronous  Transfer 
Modes  (STM)  have  been  so  far  specified: 


STM-1  :  155.52  Mb/s 
STM-4  :  622.08  Mb/s 
STM-16:  2488.32  Mb/s 


The  North  American  version  of  the  standards  uses  a  basic  transport  module 
of  51.84  Mb/s  (Synchronous  Transport  Signal-Level  1,  STS-1)  and  as  described  by 
Ballart  and  Ching''”. 

In  addition  to  optical  interfaces  for  the  above  synchronous  bit  rates  (SONET  - 
Synchronous  Optical  Network),  CCITT  Working  Party  XVIil/7  has  agreed  to 
standardize  an  STM-1  electrical  interface  for  inclusion  in  Recommendation  G.703. 
SONET  is  defined  in  the  U.S.  by  the  ANSI  standards  as  listed  below. 


T1. 105-1988 
T1. 106-1988 
T1.105-1990a 
T1  .xxx-1990 


Optical  Interface  Rates  &  Formats 

Optical  Interface  Specifications:  Single-mode 

Addendum  (in  voting  process) 

Optical  Interface  Specification:  Short  Reach  (in  voting 
process) 
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T1.yyy-1990 


SONET  OAM&P  specification  (drafted,  voting  to  begin  11/90) 


Figure  2.1  compares  the  new  synchronous  digital  hierarchy  with  the  existing 
digital  hierarchy. 

The  general  structure  and  service  capabilities  of  the  ISDN  are  defined  in  a 
total  of  77  CCITT  Recommendations  1.1 10  through  1.605.  Within  this  set. 
Recommendation  1.121  provides  the  basic  description  of  the  B-ISDN.  Much  of  the 
material  in  the  following  paragraphs  is  derived  from  this  Recommendation. 

Asynchronous  transfer  mode  (ATM)  is  the  target  transfer  mode  solution  for 
implementing  a  B-ISDN.  It  will  influence  the  standardization  of  digital  hierarchies 
and  multiplexing  structures,  switching  and  interfaces  for  broadband  signals. 

ATM  concerns  a  specific  packet-oriented  transfer  mode  using  the 
asynchronous  time  division  multiplexing  technique:  the  multiplexed  information 
flow  is  organized  in  fixed  size  blocks,  called  cells.  A  cell  consists  of  a  user 
information  field  and  a  header;  the  primary  role  of  the  header  is  to  identify  cells 
belonging  to  the  same  virtual  channel  on  an  asynchronous  time  division  multiplex. 
Cells  are  assigned  on  demand,  depending  on  the  source  activity  and  the  available 
resources.  Cell  sequence  integrity  on  a  virtual  channel  is  preserved  by  the  ATM 
layer. 

ATM  is  a  connection-oriented  technique.  Header  values  are  assigned  to  each 
section  of  a  connection  when  required  and  released  when  no  longer  needed.  The 
connections  identified  by  the  headers  remain  unchanged  during  the  lifetime  of  a 
call.  Signalling  and  user  information  are  carried  on  separate  virtual  channels.  ATM 
will  offer  a  flexible  transfer  capability  common  to  all  services,  including 
connectionless  services. 

Conversational  Services 


Conversational  services  in  general  provide  the  means  for  bidirectional 
dialogue  communication  with  real-time  (no  store-and -forward)  end-to-end 
information  transfer  from  user  to  user  or  between  user  and  host  (e.g.  for  data 
processing).  The  flow  of  the  user  information  may  be  bidirectional  symmetric, 
bidirectional  asymmetric  and  in  some  specific  cases  (e.g.  such  as  video 
surveillance),  the  flow  of  information  may  be  unidirectional.  The  information  is 
generated  by  the  sending  user  or  users,  and  is  dedicated  to  one  or  more  individual 
communication  partners  at  the  receiving  site.  Examples  of  broadband 
conversational  services  are  videotelephony,  video  conference  and  high  speed  data 
transmission. 
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Customer  Premises  CentrnI  Olllce 
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Information  Flows 


Video  service  information  can  be  characterized  in  many  ways,  including: 

The  direction  of  information  flow:  video  services  may  be  bidirectional, 
e.g.  videotelephony  and  videoconference,  or  essentially  unidirectional, 
e.g.  video  distribution  services  for  business  and  entertainment. 

The  symmetry  of  information  flow:  messaging,  retrieval  and 
distribution  services  are  characterized  by  asymmetrical  information 
flows. 

The  origin  of  the  source  material:  how  video  signals  enter  the 
network  (e,g.  direct  from  camera,  from  storage  media,  via  satellite  or 
other  delivery  mechanisms)  can  also  provide  a  means  of  characterizing 
service  information  flows. 

The  B-ISDN  will  be  based  on  ATM  techniques  which  are  well  suited  to 
supporting  source  traffic  which  is  time  varying.  The  establishment  of  virtual 
connections  which  involve  the  transfer  of  information  only  when  required  will  mean 
that  the  resources  of  the  network  can  be  closely  matched  to  the  needs  of  the 
source  traffic. 

ATM  Performance  Parameters  which  are  of  concern  for  the  VTC  application  core. 
Cell  Loss  Ratio 
Cell  Error  Ratio 
Cell  Transfer  Delay 
Mean  Cell  Transfer  Delay 
Cell  Delay  Variation 

2.3  FTS-2000 

The  FTS-2000  Project  was  initiated  by  the  General  Services  Administration 
in  the  mid-1980's  to  provide  standard  common  carrier  telephone  network  services 
to  Government  agencies  that  would  satisfy  other  than  specialized  information 
resources  needs.  Contracts  were  awarded  in  1988  to  two  common  carriers,  AT&T 
and  SPRINT  for  FTS-2000  services.  The  networks  operated  by  these  carriers  are 
referred  to  as  Network  A  and  Network  B,  respectively.  Individual  agencies  are 
assigned  to  either  network  in  accordance  with  a  plan  to  maintain  a  specific 


percentage  traffic  distribution  between  the  networks  at  the  time  of  the  1988 
award. 

The  services  provided  to  users  have  been  expanded.  Currently  Switched 
Data  Services  (SDS)  and  Dedicated  Transmission  Services  (DTS)  are  available 
Compressed  Video  Transmission  Services  (CVTS)  is  now  being  provided  on  the 
networks.  Its  inclusion  requires  specific  requests  for  the  service  from  user 
agencies. 
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3.0  VIDEO  TRANSPORT  VIA  LANS/MANS 


3.1  LAN/MAN  OVERVIEW 

A  local  area  network  (LAN)  is  a  communications  network  that  provides 
interconnection  of  a  variety  of  data  communicating  devices  within  a  small  area. 

The  most  common  occurrence  is  a  network  that  is  confined  to  a  single  building. 
Networks  that  span  several  buildings,  such  as  on  a  college  campus  or  military  base, 
are  also  common.  Another  element  that  could  be  added  to  the  definition  is  that  a 
local  network  is  generally  privately  owned  rather  than  a  public  or  commercially 
available  utility.  Indeed,  typically,  a  single  organization  will  own  both  the  network 
and  the  attached  devices.  Some  of  the  typical  characteristics  of  local  networks 
are: 

single  organization  proprietorship 

distances  involved  are  of  the  order  of  a  few  miles  and  in  the  general 
locality 

the  deployment  of  some  type  of  switching  technology 
a  transmission  medium  is  shared  among  the  attached  devices 
transmission  is  in  the  form  of  packets 

a  transmission  from  any  one  station  is  received  by  all  other  stations 
(hence  the  term  "packet  broadcasting" 

there  is  no  master  station;  rather,  all  of  the  stations  cooperate  to 
assure  orderly  use  of  the  transmission  medium 
high  data  rate  (0.1  -  100  mbps) 
low  error  rates  (10  ®  to  10  ”) 

In  recent  years,  a  new  type  of  network,  referred  to  as  a  metropolitan  area 
network  (MAN),  has  been  developed.  A  metropolitan  area  network  shares  the 
characteristics  listed  above  with  the  LAN;  the  difference  is  that  the  MAN  covers 
larger  distances  and,  generally,  operates  at  higher  data  rates. 

The  LAN  and  MAN  are  distinguished  from  wide-area  networks  (WANs).  As 
the  name  implies,  WANs  are  networks  that  cover  substantial  distances.  Public 
telephone  networks  and  packet-switching  networks  are  examples  of  WANs.  Table 
3-1  summarizes  some  of  the  key  characteristics  of  LANs,  MANs,  and  WANs. 

The  IEEE  Standards  organization  has  assumed  responsibility  for  the 
development  of  LAN  and  MAN  standards.  The  standards  which  have  been 
developed  are  illustrated  in  Figure  3.1. 
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Figure  3.1 

The  IEEE  802  LAN  Standards 


TABLE  3-1  Characteristics  of  LANS,  MANS,  and  WANS 


Network  Data  Rate  Distance  Covered 

Local  Area  Network  1-20  Mbps  <  25  km 

(IEEE  802) 


Fiber  Distributed  Data  Interface  100  Mbps 

Metropolitan  Area  Network  30  Mbps-1'^Gps 
(IEEE  802.6) 

Traditional  Wide-Area  Network  10  kbps-1.5  Mbps 

High-Speed  Wide-Area  50  Mbps-l'^Gbps 

Network 


<  200  km 
<160  km 

unlimited 

unlimited 


MAC  and  LLC 

■  The  OSI  data  link  layer  of  LANs  (layer  2)  is  decomposed  in  to  the 
media-access  control  (MAC)  and  the  logical-link-control  (LLC 
sublayers. 

■  The  MAC  sublayer  regulates  the  access  to  the  channel  shared  by 
nodes  on  a  LAN. 

■  The  LLC  sublayer  supervises  the  packet  links  between  nodes. 
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■  The  efficiency  of  a  MAC  protocol  is  the  maximum  fraction  of  time  that 
the  nodes  can  transmit  packets  successfully  when  they  use  the 
protocol  and  when  the  network  is  heavily  loaded  by  many  nodes. 

■  The  throughput  of  a  LAN  is  the  maximum  rate  of  successful  bit 
transmissions  on  the  LAN  when  it  is  heavily  loaded  by  many  nodes. 
The  throughput  is  the  product  of  the  transmission  rate  and  the 
efficiency  of  the  MAC  protocol. 

Networks  based  on  the  IEEE  802.3  standards  compose  the  most  widely  used 
LANs.  These  are  bus  networks  (see  Figure  3.2)  that  use  media-access  control 
protocol  called  carrier  sense  muitipie  access  with  coiiision  detection  (CSMA-CD). 

Token  ring  networks  are  another  widely  used  family  of  LANs.  The  token  ring 
networks  (see  Figure  3.2)  were  developed  by  IBM  in  the  early  1980s.  The 
transmission  medium  is  typically  a  twisted  pair  or  a  coaxial  cable,  although  some 
versions  use  optical  fibers.  The  MAC  protocol  of  the  token  ring  is  as  follows:  A 
specific  bit  pattern,  called  the  token,  circulates  on  the  ring.  When  a  node  wants  to 
transmit,  it  waits  until  the  token  comes  by.  It  then  replaces  the  token  with  another 
pattern  (SFD)  which  indicates  the  start  of  frame,  and  it  appends  its  packet.  The 
node  converts  the  token  in  to  an  SFD  by  monitoring  the  signal  it  receives  from  the 
ring  and  by  modifying  the  token  while  it  is  stored  in  the  interface  buffer  before 
retransmitting  it.  Once  the  packet  has  been  transmitted,  the  node  transmits  the 
token,  which  then  becomes  available  to  another  node. 

It  is  useful  to  visualize  the  location  of  the  IEEE  802  protocol  standards  in  the 
context  of  other  related  protocol  stacks.  Table  3-2  compares  the  OSI  layers  to 
CCITT,  TCP/IP,  and  IEEE  802.  Note  that  TCP/IP  is  frequently  combined  with 
Ethernet  to  form  a  total  protocol  stack. 
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TABLE  3-2  Common  Protocol  Layers 


OSI 

CCITT 

DOD 

IEEE  802 

7. 

Application 

6. 

Presentation 

Various 

5. 

Session 

4. 

Transport 

TCP 

3. 

Network 

X.25 

IP 

2. 

Link 

LAP-B 

Logical  link  control 
Medium  access 

control 

1. 

Physical 

X.21 

Physical 

FIGURE  3.2 
LAN  TOPOLOGIES 
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Fiber  Distributed  Data  Interface 


The  fiber  distributed  data  interface  (FDDI)  is  a  network  standard  developed 
by  the  American  National  Standards  Institute  (ANSI)  that  specifies  a  100-Mbps 
optical  fiber  ring  network.  The  fiber  distributed  data  interface  (FDDI)  network  is  a 
dual-ring  network  connecting  nodes  with  a  maximum  length  of  the  fiber  of  200  km. 
In  the  literature,  FDDI  is  generally  considered  to  be  a  LAN  and,  indeed,  most  of  the 
existing  installations  are  within  a  single  building  or  small  cluster  of  buildings.  FDDI 
is  designed  to  provide  high  end-to-end  throughput  between  expensive,  high-speed 
devices  such  as  mainframes  and  mass  storage  devices.  It  is  also  used  as  a 
backbone  network  to  connect  a  number  of  lower-speed  LANs.  Table  3-3  is  a 
comparison  of  FDDI  and  802.5  parameters. 

As  with  the  typical  LAN,  FDDI  was  originally  defined  to  use  packet 
broadcasting  and  to  support  data  traffic.  A  recent  enhancement  to  the  standard, 
known  as  FDDI-II,  provides  support  for  voice  traffic  and  other  applications  that 
normally  use  circuit  switching. 


TABLE  3-3  Differences  Between  FDDI  and  802.5 


FDDI 

802.5 

Optical  fiber 

Shielded  twisted  pair 

100  Mbps 

4.16  Mbps 

Reliability  specification 

No  reliability  specification 

4B/5B  code 

Differential  Manchester 

Distributed  clocking 

Centralized  clocking 

Timed  token  rotation 

Priority  and  reservation  bits 

New  token  after  transmit  New  token  after  receive 

ATM 


The  Asynchronous  Transfer  Mode  (ATM)  format  was  developed  to  fulfill  a 
WAN  requirement  within  the  B-ISDN.  However,  the  format  also  lends  itself  for  use 
as  a  wideband  LAN  and  is  beginning  to  find  significant  use  in  this  mode.  Shared 
media  ATM  networks  include  DQDB,  the  Cambridge  Fast  Ring,  the  Cambridge 
Backbone  Ring,  the  Orwell  Ring,  and  the  recently  proposed  ATM  Ring.  There  are  a 
number  of  solutions  based  on  interconnected  switches  to  form  general  topology 
networks. 
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GENERAL  VTC  PERFORMANCE  ISSUES  FOR  LAN/WAN  MEDIA 


Today,  virtually  all  video  teleconferencing  is  transmitted  via  synchronous 
transmission  circuits  such  as  switched  56  Kbps  and  T1  lines.  LANs  and  WANs  are 
fundamentally  different  from  these  networks  in  many  ways,  and  some  of  these 
differences  can  contribute  to  degraded  VTC  performance  unless  precautions  are 
taken.  Some  of  the  technical  issues  which  must  be  carefully  considered  in  the 
design  of  a  VTC  system  via  LANs  are  listed  below. 

The  throughput  bitrate  allocated  to  one  particular  user  usually  fluctuates 
depending  upon  the  number  of  active  users  and  overall  traffic  through  the 
network.  If  the  volume  is  very  high,  the  available  bitrate  may  be  so  low  the 
quality  is  significantly  degraded. 

Packet  loss  from  LANs  can  cause  a  more  serious  degradation  to  the 
audiovisual  signals  than  distributed  bit  errors  associated  with  synchronous 
links. 

Occasional  serious  interruptions  in  the  connection  are  much  more  likely  in 
LANs  than  synchronous  connections.  When  such  problems  occur,  the  audio 
signal  can  be  rendered  almost  useless.  It  is  interesting  to  note  that  the  audio 
is  far  more  critical  in  VTC  sessions  than  the  video.  If  the  audio  is  unusable, 
the  conference  is  unusable  regardless  of  the  video.  However,  it  is  also 
interesting  to  note  that  "useful"  video  (e.g.  still  pictures)  can  be  transmitted 
under  surprisingly  adverse  conditions. 

In  order  to  achieve  an  interactive  VTC  service,  the  communication  media 
must  have  low  delay.  In  the  LAN  situation,  this  means  that  the  packet  rate 
must  be  high  enough  to  achieve  low  latency.  In  many  LANs  where  the 
payload  bits/packet  is  fundamentally  high,  this  will  dictate  that  the  bitrate  for 
the  audio  is  governed  by  the  network  rather  than  the  source  signal  itself. 

3.2  VTC  Products  and  Applications 

There  is  a  great  deal  of  activity  in  the  use  of  LANs  for  video 
teleconferencing.  A  large  number  of  commercial  products  are  available  for  this 
application,  and  there  is  work  to  develop  standardized  terminals  for  VTC  over  LAN. 
work  in  these  two  areas  is  described  below. 
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3.2.1  Commercial  Products 


Examples  of  commercial  products  for  providing  VTC  services  over  LANs  are 
listed  in  Table  3-4  and  brochures  are  included  in  Appendix  3.1. 

3.2.2  VTC  Standards 

At  the  September  1993  meeting  of  the  ITU  SGI  5,  Mr.  Okubo  was  appointed 
Rapporteur  to  adapt  the  H.320  Recommendations  for  operation  over  LAN 
networks.  The  modified  Recommendations  have  been  designated  as  H.32Z. 


TABLE  3-4  Desktop  Videoconferencing  Products  Using  LANs 
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TCP/IP  Used  for  Higher  Layers 


4.0  VIDEO  TRANSPORT  VIA  THE  PSTN 


4. 1  Overview 

The  Public  Switched  Telephone  Network  (PSTN)  is  so  universal  and 
ubiquitous  that  no  description  is  required.  It  provides  telephone  service  reliably  and 
inexpensively  to  literally  all  parts  of  the  world.  One  good  measure  of  the  leverage 
and  power  of  the  PSTN  is  the  recent  Group  3  facsimile  revolution.  No  one 
remotely  visualized  the  potential  for  G3  fax  because  no  one  fully  appreciated  the 
value  of  a  PSTN  connection. 

A  number  of  recent  technological  breakthroughs  have  made  it  possible  to 
realistically  provide  videophone  service  over  the  PSTN.  These  developments  are 
listed  below. 


advanced  video  and  speech  compression  technology 
advanced  PSTN  modem  technology  (Up  to  28  Kbps) 
development  of  packet  transmission  techniques 
low  cost  VLSI  technology 

Several  companies  have  developed  PSTN  videophones.  AT&T  and  Marconi 
are  now  actively  marketing  units  to  the  consumer  on  a  worldwide  basis.  All  PSTN 
videophones  which  have  been  developed  are  discussed  in  Section  4.2. 

The  ITU  has  initiated  an  "urgent"  program  to  develop  an  international 
standard  for  the  PSTN  videophone.  The  schedule  calls  for  the  development  of  a 
stable  draft  by  November  1994.  This  standardization  effort  is  described  in  section 
4.3.  In  section  4.4  implications  of  the  PSTN  videophone  for  the  Government 
community  are  presented. 

4.2  Commercial  Products  and  Applications 

Table  4-1  is  a  summary  of  the  technical  characteristics  of  existing  PSTN 
videophones.  Marconi  manufactures  a  unit  which  is  marketed  by  British  Telecom 
and  MCI.  The  AT&T  unit  is  designated  as  the  Model  2500.  The  Marconi  and 
AT&T  products  have  been  marketed  extensively  to  the  consumer  in  1993. 
Comtech  and  Sharevision  have  developed  products  but  not  marketed  as  intensely. 
The  Sharevision  product  is  interesting  because  it  includes  an  interactive  data 
capability  to  make  it  particularly  applicable  to  a  PC  workstation.  The  European 
Cost  21  Iter  and  Bosch  products  are  being  tested  and  evaluated.  Brochures  on 
some  of  these  products  are  included  in  Appendix  4.1. 
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TABLE  4-1 

Technical  Characteristics  of  Existing  PSTN  Videophones 


Hardware  Demonstrator  Model 
MPEG  Notation 

It  is  recognized  that  V.FAST  is  not  an  approved  standard  at  this  time. 


TABLE  4-1 
CONTINUED 


(4)  Provision  for  a  separate  user  data  channel  is  not  provided. 


4.3  Standardization  Activity 


In  1992  the  ITU-TS  appointed  a  Rapporteur  to  perform  a  study  to  determine 
the  feasibility  of  developing  a  Recommendation  for  a  PSTN  videophone.  The  study 
was  completed  in  September  1993  and  recommended  that  work  be  initiated  to 
develop  a  near  term  Recommendation  (1995)  to  be  followed  by  an  enhanced 
version  in  1998.  The  ITU-TS  has  re-appointed  the  Rapporteur  to  develop  these 
Recommendations  as  detailed  in  Table  4-2  and  Figure  4.1.  (See  Appendix  5.3.) 

TABLE  4-2 

ITU-T  Recommendations  for  the  Very  Low  Bitrate  Videophone 


FUNCTIONAL  ELEMENT 

NEAR  TERM  (1995) 

LONG  TERM  (1998) 

SYSTEM 

H.32P 

VIDEO  CODER 

H.26P 

H.26P/L 

SPEECH  CODER 

AV.25Y 

WP  15/2 
(4Kbps) 

DATA  INTERFACE 

Based  On  MLP  or  HDLL 

H.DLP 

SUPERVISION  CONTROL 

H.24P 

MULTIPLEX/ 

ERROR  CONTROL 

H.22P 

MODEM 

PSTN 

V32  bis,  V34/V8  (VFAST) 

MOBILE 

RADIO 

FPLMTS 

li  II 


Recommendation  will  not  be  developed  by  WP  15/1. 


PSTH 

OR 

MOBILE 

RADKD 

NETWORK 


•  Conrect  structure  for  PSTN  vibaophone;  mey  require  ellqht  modiflcation  for  nx)We  radio  videophone. 


FIGURE  4.1 

FUNCTIONAL  BLOCK  DIAGRAM  FOR  VERY  LOW  BITRATE  VIDEOPHONE 

The  status  of  each  of  the  Videophone  Recommendations  being  developed  is 
summarized  below. 

PSTN  Modem 

V.32bis  (9.6  and  14.4  Kbit/s)  and  V.FAST  (up  to  28.8  Kbit/s)  modems  are 
mature  and  would  be  employed,  thereby  greatly  increasing  the  system's 
performance  relative  to  existing  videophone  products. 

H.26P  -  Video  Coder 

The  near  term  video  codec  will  provide  significant  improvement  in  picture 
quality  relative  to  H.261,  when  adapted  to  videophone,  as  demonstrated  by 
computer  simulation.  Potential  improvements  result  from  sub-pel  motion 
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compensation,  reduced  overhead,  and  motion  compensation  at  the  biock  level. 
Picture  formats  being  considered  include  QCIF  and  lower  resolutions. 

H.26/L  -  Long  Term  Video  Coder 

The  underlying  source  model  of  the  current  standards  is:  2D  rigid 
translationally  moving  blocks  containing  highly  correlated  pels.  In  general,  this  is 
only  a  very  rough  approximation  of  reality.  Differences  in  subsequent  images  are 
caused  by  motion  of  objects,  but  also  by  camera  motion  (zoom,  pan),  camera 
noise,  lighting  effects,  changes  in  the  shape  of  objects,  occlusion  of  objects  and 
background,  scene  cuts,  etc.  Even  when  differences  in  subsequent  images  are 
only  caused  by  motion  of  objects,  the  prediction  may  be  suboptimal  because: 

the  size  of  the  prediction  block  (16*16)  is  too  large; 

3-D  translations  and  rotations  occur; 
fractional  pixel  displacements  may  occur; 
the  search  window  may  be  too  small; 

the  search  criterion  may  be  suboptimal,  for  example,  in  case  of 
lighting  effects; 

the  image  in  the  frame  memory  contains  quantization  noise. 

New  video  coding  techniques,  with  better  underlying  source  models,  have 
recently  appeared  in  literature.  These  techniques  have  been  classified  in  Table  4-3. 
Work  is  underway  in  the  ITU  and  ISO  MPEG4  organizations  to  develop  a  long  term 
video  coding  standard  using  technology  of  this  type. 

H.DLP  -  Data  Interface 

An  optional  data  channel  will  be  included  to  be  multiplexed  with  the  audio 
and  video  signals.  Provision  for  high  resolution  still  images  using  JPEG  standard 
will  be  provided.  It  is  a  goal  to  interwork  with  other  related  ITU  Recommendations. 
H.320  terminals  and  some  existing  videophone  products.  Table  4-4  is  an  example 
of  a  bitrate  budget  for  the  various  virtual  channels. 
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TABLE  4-3 

Classification  of  Coding  Techniques 
Based  on  Source  Models 


LEVEL 

SOURCE  MODEL 

CODED  INFORMATION 

CODING  TECHNIQUE  j 

1 

Pels 

Color  of  pels 

PCM 

2 

Statistically 
dependent  pels 

Color  of  pels  or  block  of 
pels 

predictive  coding 
transform  coding 

3 

Translationally 
moving  blocks 

Color  of  blocks  and 
motion  vectors 

Motion  compensated 
hybrid  DPCM/DCT 
coding 

4 

Moving  structures 

Mapping  parameters  or 
shape  and  motion 

Fractal  coding 

contour/texture 

coding 

5 

Moving  unknown 
objects 

Shape,  motion  and  color 
of  each  object 

Analysis/synthesis 

coding 

6 

Moving  known 
object 

Shape,  motion  and  color 
of  the  known  object 

Knowledge  based 
coding 

7  1 

Facial  expressions 

Action  units 

Semantic  coding 

H■22P  -  Multiolex/Error  Control 

It  is  proposed  to  employ  packetized  network  and  link  layers  to  adaptively 
multiplex  several  virtual  circuits  --  speech,  video,  data,  and  supervision.  This 
provides  a  greater  degree  of  flexibility,  and  evolutionary  growth  potential,  than 
TheSpeech  Coder 

The  near  term  speech  coder  (AV.25Y)  is  to  achieve  as  near  toll  quality  as 
possible  given  the  bit-rate  budget.  The  long-term  speech  coder  is  expected  to 
achieve  toll  quality  at  4kbps.  The  long-term  work  has  been  referred  to  the  speech 
experts  within  Working  Party  1 5/2. 


Schedule 


The  ITU  has  assigned  an  "urgent  priority  to  the  PSTN  Videophone  program, 
and  the  schedule  for  the  near  term  recommendations  is  outlined  below. 

WP  15/1  Meeting  Date  Target  Status  of  the  Near  Term  Recommendations 


March  *94  Initial  Draft  Completed 

November  ’94  Draft  Stabilized/Frozen 

February  '95  SGI  5  Applies  for  Resolution  1  Approval 

November  '95  ITU  distributes  Draft  Recommendation  for 

Approval  by  ballot 


TABLE  4-4 

Example  of  a  Bitrate  Budget  for  Very  Low 
Bitrate  Visual  Telephony  (kbit/s) 


9.6 

Kbps 


Overall 
Trans¬ 
mission 
Bit  Rate 


Virtual  Channel 


Overhead/ 

Supervision 

(5%) 


Speech 


Video 


0.5  Kbps 


4.8  Kbps 


6.8 


4.3  Kbps'*' 


2.3'*’ 


8.9 


Variable 


4.8 

16.7 

6.8 

14.7 

Variable 


Virtual 

Channel 

Bitrate 

Characteristic 


Variable 

Bitrate 


High 

Priority 


4.8 

22.6 

6.8 

20.6 

Dedicated, 

Fixed 

Bitrate 

Variable 

Bitrate 

High 

Priority 

Lowest 

Priority 

Variable 


Variable 

Bitrate 


Higher  Than 
Video,  Lower 
Than 

Overhead/ 

Speech 


(1)  The  plan  includes  consideration  of  advanced  speech  codec  technology  such  as...  (a)  a  dual 
bitrate  speech  codec  (b)  reduced  bitrate  when  voiced  speech  is  not  present. 

(2)  Achievement  of  motion  video  is  considered  to  be  questionable  at  4.3  Kbps  and  inadequate  at 
2.3  Kbps. 

(3)  V.FAST  operates  at  increments  of  2.4  Kbps;  i.e.  16.8,  19.2,  21.6,  24.0,  26.4,  28.8  Kbps. 

(4)  The  channel  priorities  will  not  be  standardized;  the  priorities  indicated  are  examples. 
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4.4  IMPLICATIONS  FOR  THE  GOVERNMENT 

It  is  concluded  from  Section  4.3  that  a  series  of  ITU  Recommendations 
(H.32P)  will  be  developed  in  the  near  term  for  videophone  and  workstation 
interaction  via  the  PSTN.  It  is  likely  that  these  Recommendations  will  have  a  major 
Impact  on  the  telecommunications  structure  within  the  Government  community  for 
the  following  reasons. 

At  the  current  time,  the  presence  of  ISDN  in  the  government  is  very 
restricted,  and  the  timetable  for  its  Introduction  is  very  speculative. 
These  is  no  question  that  ISDN  will  one  day  be  available  In  most 
government  installations.  The  only  question  is;  When?  The  PSTN  is 
ubiquitous  and  pervasive  today  and  will  continue  to  be. 

Regardless  of  the  ISDN  timetable  which  will  evolve,  there  will  be  some 
government  installations  in  remote  locations  which  will  not  receive 
ISDN  for  many  years. 

In  many  national  emergency  scenarios,  the  PSTN  would  probably  be 
more  available  than  ISDN. 

The  V.FAST  modem  standard,  which  will  be  finalized  shortly,  provides 
a  high  transmission  bit  rate  --  approximately  25  Kbps. 

The  PSTN  videophone  could  provide  an  entry  into  the  video  phone 
service  from  which  a  user  could  migrate  to  the  more  capable  ISDN 
video  phone  service. 

The  PSTN  videophone  and  ISDN  video  phone  will  be  interoperable. 

The  development  of  the  international  facsimile  standard  by  the  ITU 
created  a  quantum  leap  in  the  use  of  the  PSTN  for  wide  variety  of 
services  which  was  very  difficult  to  anticipate  or  predict.  The 
development  of  Recommendation  H.32P  could  have  a  similar  Impact. 

Regional  standards  projects 'for  the  PSTN  videophone  are  underway. 
The  ITU  Near-Term  Project  makes  it  possible  for  an  International 
Standard  rather  than  a  Regional  one. 
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+  ETSI  has  a  project  to  develop  a  Draft  Standard  for  a  PSTN 
Videophone  in  late  1995. 

+  TIAI.5  has  initiated  a  project  to  develop  an  ANSI  standard  for 
the  PSTN  videophone. 
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5.0  VIDEO  TRANSPORT  VIA  MOBILE  RADIO 

5.1  Mobile  Radio  Overview 

5.1.1  Analog  Cellular  Radio 

AMPS  (Advanced  Mobile  Phone  System)  is  the  current  air  interface  standard 
for  the  analog  cellular  system  in  the  United  States.  At  the  time  of  this  writing,  the 
system  is  dominant  throughout  North  America  and  has  achieved  a  moderate 
amount  of  penetration  on  other  continents  as  well.  With  an  installed  worldwide 
subscriber  base  in  excess  of  10  million  units,  it  is  highly  probable  that  AMPS  will 
survive  past  year  2000.  A  newer  AMPS-like  specification  known  as  NAMPS  has 
the  potential  to  double,  or  triple,  the  number  of  analog  subscribers  in  North 
America  and  provide  some  additional  features  now  common  to  most  digital  cellular 
standards. 

The  AMPS  air  interface  is  currently  specified  by  the  American  National 
Standards  Institute,  Electronic  Industries  Association  (EIA),  and 
Telecommunications  Industry  Association  (TIA).  The  current  version  is  known 
simply  as  EIA/TIA-553.  The  base  station  transmit  and  receive  bands  are  separated 
by  45  Mhz.  The  channel  spacing  is  30  Khz,  and  each  operator  within  a 
geographical  area  is  allocated  exactly  half  of  the  available  channels  (416)  for 
control  and  voice.  The  modulation  technique  for  the  user  voice  is  frequency 
modulation. 

Narrowband  AMPS  (NAMPS)  is  the  name  given  to  a  more  recent  air  interface 
compatibility  specification  recently  sanctioned  by  the  TIA.  The  current  interim 
specification  is  divided  into  three  parts:  IS-88  (air  interface),  IS-89  (base  station 
requirements),  and  IS-90  (mobile  station  requirements).  NAMPS  is  a  direct 
descendent  of  Narrowband  Total  Access  communication  System  (NTACS),  which  is 
now  enormously  popular  in  Japan. 

NAMPS  takes  each  30-Khz  AMPS  channel  and  splits  it  into  three  10-Khz 
channels.  Each  cellular  call  is  allocated  a  10-Khz  channel  in  NAMPS  just  as  call  is 
allocated  a  30-Khz  channel  in  AMPS.  The  resulting  three-for-one  split  results  in  an 
increase  in  system  capacity  without  the  overhead  of  cell  splitting  and  all  its 
attendant  headaches.  NAMPS  is  compatible  with  the  AMPS  system  in  that  the  30- 
Khz  control  channel  is  still  used  and  mobile  stations  can  be  built  to  handle  both 
standards  beyond  increased  capacity  which  makes  it  attractive. 

In  the  near  term,  AMPS  will  remain  a  viable  cellular  technology,  offering 
enhancement  features  of  interswitch  or  intermanufacturer  handoff  (IS-41)  and 
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roaming.  However,  limitations  in  capacity  and  over-the-air  call  features  (e.g., 

ISDN)  requiring  greater  bandwidth  will  hamper  AMPS  from  competing  with  future 
digital  technologies. 

5.1.2  Digital  Cellular  Radio 

Digital  cellular  technology  provides  solutions  to  the  capacity  problem  and 
other  issues  prevalent  in  today's  analog  cellular  systems.  Improvements  in  the 
areas  of  mobility,  cost,  power  consumption,  and  spectrum  utilization  are  provided 
by  conversion  to  digital  as  listed  below. 

Increased  radio  frequency  spectrum  efficiency  and  system  capabilities 
Digital  multiple  access  techniques  (MATs)  are  being  developed  to 
provide  additional  capacity  within  the  current  spectrum  allocations  for 
cellular  communications.  Analog  systems  cannot  provide  these 
advanced  capabilities. 

A  signal  that  can  be  almost  free  of  noise  and  interference  impairments 
Digital  techniques  support  error  correction  so  that  most  static,  fading, 
and  other  disturbances  to  the  radio  channel  are  undetectable  to  the 
customer  or  negligible  compared  to  today's  analog  noise  problems. 

Low  power  consumption  by  the  system  components 
Digital  components  use  less  power  than  analog  components. 

Improved  security  features  and  services 

Because  it  is  easier  to  encrypt  a  digital  signal  than  an  analog  signal, 
customers  will  benefit  from  higher  levels  of  security  services. 

Digital  cellular  is  in  the  developmental  stage  in  the  U.S.  Key  issues 
remaining  to  be  resolved  are  listed  below. 

Ensuring  interoperability  and  compatible  interfaces  to  current  analog 
systems  during  the  transition  to  a  completely  digital  environment. 

This  may  be  accomplished  via  a  dual  mode  system  in  the  transition 
period. 

Providing  customers  complete  mobility  to  communicate  anywhere  with 
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cellular  phones,  pagers,  pocket  phones,  and  wireless  Private  Branch 
Exchanges  (PBXs).  This  capability  heralds  widespread  use  of  the 
Personal  Communications  Services  (PCS). 

Implementing  network  architectures  that  eliminate  current  multipath 
fading  environments  and  ensure  soft  (no-break)  hand-offs. 

Developing  a  seamless  internetwork  architecture  that  allows  users  to 
roam  nationwide  or  even  worldwide.  Such  an  architecture  implies 
implementation  of  an  Intelligent  Network  (IN)  that  has  a  common  data 
base  and  provides  customer  identification  and  service  as  the  user 
travels  about  the  seamless  environment. 

Satisfying  customer  demand  for  improved  security  services.  The 
authentication  and  additional  security  services  provided  by  digital 
systems  will  minimize  fraud  and  other  security  problems  common 
today. 

Agreeing  on  a  standard  multiple  access  technique.  On  January  6, 
1992,  the  Board  of  Directors  of  the  Cellular  Telecommunications 
Industry  Association  (CTIA)  unanimously  passed  a  resolution  stating 
that  time  division  multiple  access  (TDMA)  should  remain  the  industry 
standard  for  digital.  CTIA  is  the  primary  association  promoting  digital 
cellular  standards  in  the  United  States.  TDMA  and  two  other 
advanced  multiple  access  techniques  are  discussed  in  more  detail 
below. 

Time  Division  Multiple  Access  (TDMA) 

In  the  proposed  TDMA  system,  each  communications  channel,  which  is  30 
kilohertz  (Khz)  wide,  is  shared  by  several  users.  TDMA  divides  a  channel  into  six 
time  slots  and  assigns  two  time  slots  to  each  user.  By  so  doing,  TDMA  allows 
three  users  to  share  the  channel  bandwidth.  CTIA  has  proposed  a  40-millisecond 
frame  to  be  shared  equally  among  the  three  users  of  the  same  channel.  Applying 
this  time  period  to  TDMA  represents  a  fivefold  increase  in  channel  sharing  capacity 
over  the  current  analog  FDMA  system. 

Code  Division  Multiple  Access  (CDMA) 
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CDMA,  the  second  MAT  being  proposed  within  the  digital  cellular  industry, 
employs  wideband  transmission  techniques  to  achieve  capacity  gains.  CDMA,  also 
known  as  spread  spectrum,  was  developed  for  military  applications  just  after  World 
War  11.  In  CDMA  transmission,  each  user's  baseband  signal  is  dispersed  over  the 
entire  1.25  Mhz  channel.  CDMA's  system  gain  is  due  to  the  sharing  of  the  same 
1.25  Mhz  channel  by  many  users,  each  at  a  low  power  level.  Each  signal's  power 
is  spread  over  the  whole  1.25  Mhz  bandwidth  so  that  each  user's  contribution  of 
energy  per  hertz  is  small. 

Extended  Time  Division  Multiple  Access  (E-TDMA) 

E-TDMA,  the  third  MAT  being  proposed  by  the  industry,  is  being  developed 
by  Hughes  Network  systems  (HNS)  for  cellular  applications.  The  cellular  industry, 
however,  is  not  considering  E-TDMA  for  first  generation  digital  systems. 

HNS  is  incorporating  digital  speech  interpolation  (DSD  into  E-TDMA  to  gain 
additional  capacity.  DSI  takes  advantage  of  the  fact  that  the  average  channel 
utilization  for  speech  is  less  than  50  percent.  In  DSI,  a  user  occupies  a  channel 
only  when  the  user  is  active.  When  the  user  pauses,  the  channel  can  be 
reassigned  to  another  user.  By  having  a  large  number  of  users  sharing  a  small 
number  of  channels,  contention  often  occurs.  However,  the  collisions  will  be  brief. 

5. 1.2.1  Digital  Cellular  Standards 

The  need  for  increased  system  capacity  for  current  cellular  systems  drives 
the  development  of  digital  cellular  standards  worldwide.  Europe,  Japan,  and  the 
United  States  are  developing  digital  cellular  standards  for  their  respective  national 
cellular  communities.  Table  5-1  displays  the  technical  characteristics  of  the 
developing  digital  cellular  standards  in  North  America,  Europe,  and  Japan.  These 
efforts  are  not  being  coordinated  with  each  other,  resulting  in  three  distinct  digital 
cellular  standards  profiles.  Since  the  three  competing  cellular  standards  use 
different  technical  properties  the  networks  are  incompatible.  Due  to  the 
incompatibility  of  the  three  standards,  a  truly  interoperable  international  cellular 
network  is  currently  impossible.  However,  further  development  of  new  digital 
cellular  standards  may  eventually  provide  worldwide  seamless  roaming  to  any 
cellular  user. 
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TABLE  5-1 


Technical  Characteristics  of  Digital  Cellular  Standards 


GSM 

ADC 

JDC 

Proponent 

Europe 

United  States 

Japan 

Multiple  Access  Technique 

TDMA 

TDMA 

TDMA 

Carrier  spacing 

200  Khz 

30  Khz 

25  Khz 

Users  (channels)  per  carrier 

8 

3 

3 

Voice  bit  rate 

13  kb/s 

8  kb/s 

8  kb/s 

Carrier  bit  rate 

270  kb/s 

48.6kbs 

42kb/s 

Diversity  methods 

Frequency 

hopping 

Antenna 

diversity 

Bandwidth  per  voice  channel 

25kbz 

10  Khz 

8.3  Khz 

Required  C/1 

9  Db 

16  Db 

13  Db 

ADC:  American  Digital  Cellular 

C/I:  Carrier-to-lnterface  Ratio 

GSM:  Global  System  for  Mobile  Communications 

JDC:  Japanese  Digital  Cellular 

GSM  (EUROPE) 

The  digital  cellular  standard  closest  to  full-scale  implementation  exists  in 
Europe.  Through  the  European  Telecommunications  Standards  Institute,  a  group  of 
European  nations  developed  a  digital  cellular  standard  known  as  Groupe  Speciale 
Mobile  (GSM).  The  GSM  standards  use  a  TDMA  technique  for  efficient  use  of  the 
cellular  spectrum.  GSM  cellular  has  been  allocated  new  spectrum  in  Europe, 
separate  from  the  current  analog  frequencies.  The  new  frequencies  were  allocated 
with  the  cooperation  of  the  frequency  assignment  administrations  of  all 
participating  nations.  More  than  20  European  countries  have  signed  a 
memorandum  of  understanding  that  calls  for  GSM  service  on  the  main  transport 
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routes  between  the  European  capital  cities  by  1995. 

(ADO  UNITED  STATES 

The  United  States  is  adopting  a  dual-mode  standard,  which  allows  analog 
terminals  to  continue  using  the  current  frequencies,  and  still  allows  for  the 
improvement  in  channel  capacity  by  using  a  digital  signaling  technique.  The  TDMA 
standard  being  developed  in  the  United  States  is  often  referred  to  as  American 
Digital  Cellular  (ADC). 

The  cellular  radio  community  in  the  United  States  produces  standards  in  a 
subcommittee  sponsored  by  the  Telecommunications  Industry  Association  (TIA) 
and  the  CTIA  (Cellular  Telecommunications  Industry  Association).  TIA  and  CTIA 
have  created  the  Cellular  Standards  committee,  TR45,  to  deal  with  cellular  issues. 
There  are  five  subcommittees  that  perform  the  standards  work: 

TR45.1  -  Analog  Cellular 

TR45.2  -  Cellular  Intersystem  Operations 

TR45.3  -  Digital  Cellular 

TR45.4  -  Personal  Communications  Services 

TR45.5  -  Wideband  Spread-Spectrum  Digital  Technology 

The  current  ANSI-accredited  standard  for  analog  cellular  radio  is  Electronic 
Industries  Association/Telecommunications  Industry  Association  (EIA/TIA)  553, 
Mobile  Station-Land  Station  Compatibility  Standard.  The  most  active 
subcommittees,  TR45.2  and  TR45.3,  are  developing  Interim  Standards  to  support 
the  new  dual-mode  cellular  system  that  is  being  planned  for  the  transition  to  all 
digital  services.  The  TR45.5  subcommittee  was  established  in  early  1992  to 
investigate  a  wideband  MAT  for  digital  cellular  application.  The  TR45.1 
subcommittee  is  pursuing  a  course  to  standardize  the  N-AMPS  in  the  United  States. 

The  TIA  has  recently  completed  the  interim  standard  designated  as  IS54 
which  fully  defines  the  digital  cellular  system  for  TDMA  operation.  By  employing  3 
time  slots  a  voice  channel  has  a  gross  bitrate  of  13Kbps  and  a  net  payload  of 
8Kbps.  Deployment  of  operational  equipment  based  on  this  standard  began  in 
1993.  The  TIA  has  also  completed  an  interim  standard  based  on  CDMA 
technology  which  is  designated  as  IS96. 
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5.1.3  Personal  Communication  Services 

The  Telecommunications  Industry  Association  (TIA)  has  defined  Personal 
Communications  Services  (PCS),  or  wireless  communications,  as  "a  mobile  radio 
voice  and  data  service  for  the  provision  of  unit-to-unit  communications  which  is 
based  on  microcell  and  other  technologies  that  enhance  spectrum  capacity  to  the 
point  where  it  will  offer  potential  for  essentially  ubiquitous  and  unlimited, 
untethered  communications."  This  ambitious  definition  Is  far  more  wide-reaching 
than  the  current  wireless  reality.  Most  wireless  telecommunications  systems 
cannot  provide  reliable  communication  as  distance  becomes  a  factor,  nor  is  the 
technology  as  universal  as  the  TIA  definition  implies. 

Experts  estimate  that  PCS  will  have  1 1 5  million  subscribers  by  the  year 
2000.  Varying  user  requirements  will  lead  to  a  wide  range  of  access  methods. 
Telecommunications  industry  experts  believe  that  PCS  could  provide  a  variety  of 
services  instead  of  merely  acting  as  a  pocket-size  digital  cellular  telephone.  The 
services  could  include  wireline  and  wireiess  services  on  either  a  local  or  long¬ 
distance  basis  for  the  home  or  office. 

PCS  has  become  the  catch-all  term  for  mobile,  switched  voice  services. 
Proposed  PCSs  fali  into  two  basic  categories.  Personal  Communications  Network 
(PCN)  is  simiiar  to  existing  ceilular  systems,  but  the  cell  size  may  be  as  small  as  a 
300-foot  radius.  PCN  may  be  best  for  low-power,  low-cost  pocket  handsets.  The 
second  category,  cordless  telephone-second  generation  (CT-2),  is  essentially  a  one¬ 
way  call-out  system.  Its  chief  attraction  is  low  cost. 

5.1.4  UPT  (Universal  Personal  Telecommunications) 

UPT  is  a  telecommunications  service  concept  that  provides  for  personal 
rather  than  terminal  mobility.  This  service  concept  enables  a  person  to  initiate  and 
receive  calls  on  the  basis  of  a  unique,  personal,  network-transparent  UPT  number. 
Personal  mobility  is  conferred  by  the  user's  ability  to  access  a  telecommunications 
service  at  any  terminal.  Users  may  configure  terminals  to  meet  their  unique 
requirements,  limited  only  by  the  terminal  and  network  capabilities  and  restrictions 
imposed  by  the  network  provider.  Personal  mobility  is  limited  only  by  the 
network’s  capability  to  locate  users  on  the  basis  of  unique  UPT  numbers  used  for 
addressing,  routing,  and  charging  the  user's  calls. 

UPT  service  requires  the  transfer  of  control  information  between  various 
databases  to  establish  the  communications  environment  for  the  call.  Different  call 
handling  procedures  are  used  according  to  whether  calls  are  routed  within  a  single 
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network  or  across  multiple  networks.  The  integrated  network  functions  that  are  an 
integral  part  of  the  evolving  network  for  UPT  include  access,  transport,  intelligence, 
and  management. 

Recent  developments  in  emerging  technologies  such  as  Intelligent  Network 
(IN),  Integrated  Services  Digital  Network  (ISDN)  and  digital  cellular  communications 
are  providing  new  dimensions  to  personal  telecommunications  capabilities.  These 
capabilities  make  new  services  such  as  UPT  possible.  UPT  represents  a  complex 
concept  still  in  its  infancy,  with  the  pace  of  its  evolution  dependent  upon  market 
needs  and  advance  in  IN  technology. 

The  ANSI  T1  committee  established  the  TIPI  committee  in  late  1990  to 
define  and  develop  standards  in  the  area  of  Personal  Communications,  which 
includes  UPT.  Within  the  TIPI  committee  are  three  working  groups  responsible  for 
the  following  activities: 

T1P1.1  has  responsibility  for  program  management  within  the 
development  of  personal  communications  standards. 

TIPI. 2  has  responsibility  for  functional  requirements,  interfaces  and 
the  overall  PCS  architecture. 

TIPI. 3  has  responsibility  for  service  descriptions,  functional  models 
and  network  interfaces. 

Provision  of  UPT  will  occur  gradually,  beginning  with  a  simplified  set  of  UPT 
features  and  capabilities,  such  as  voice  only,  that  later  progresses  into  more 
advanced  scenarios  that  include  voice,  data,  and  imagery. 

The  UPT  service  is  described  as  universal  for  the  following  reasons: 

UPT  operates  on  any  terminal  on  any  network. 

UPT  supports  all  basic  telecommunications  services  (e.g.,  telephone, 
mobile,  facsimile,  video). 

•UPT  is  available  globally  (from  any  geographic  location). 

UPT  service  is  described  as  personal  for  the  following  reasons: 
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The  user  has  a  UPT  number  that  is  associated  with  the  person  rather 
than  with  a  terminal. 

Personal  mobility  (i.e.,  mobility  between  terminals)  is  provided  to  the 
user. 

UPT  enables  personalization  of  various  service  features. 

UPT  is  a  service  concept,  independent  of  the  network,  that  takes  advantage 
of  the  new  developments  in  telecommunications  such  as  the  ISDN,  Future  Public 
Land  Mobile  Telecommunications  Systems  (FPLMTS),.and  the  mobile  satellite 
systems  which  are  entering  the  telecommunications  world  in  this  decade.  Sonrie  of 
these  concepts  are  currently  being  tested,  including  second  and  third  generation 
cordless  telephone  (CT2/CT3)  and  other  experimental  wireless  services. 

5.1.5  Future  Public  Land  Mobile  Telecommunications  Systems  (FPLMTS) 

FPLMTS  are  systems  that  will  provide  telecommunications  services  to  mobile 
or  stationary  users  by  means  of  one  or  more  radio  links.  This  mobility  will  be 
unrestricted  in  terms  of  location  within  the  radio  coverage  area.  FPLMTS  will  be  an 
integral  part  of  the  Public  Switched  Telephone  Network  (PSTN)  and  will  extend  the 
telecommunications  services  of  fixed  networks  to  mobile  or  stationary  users  over 
wide  geographic  areas.  The  constraints  on  the  system  will  be  those  imposed  by 
spectrum  allocation  and  radio  propagation.  FPLMTS  will  allow  users  to  originate 
and  terminate  calls  from  small,  lightweight  portable  devices,  regardless  of  location. 
FPLMTS  will  provide  voice  grade  services  for  making  and  receiving  calls  from 
anywhere,  and  should  be  simple  to  use.  The  security  and  quality  of  FPLMTS  will 
be  comparable  to  that  of  wireline  services.  From  a  user's  perspective,  the  access 
device  will  probably  be  a  small,  shirt-pocket-sized  portable  terminal.  FPLMTS  will 
have  low-power  radio  access  to  cellular  sites  that  are  connected  to  the  PSTN. 
FPLMTS  work  is  being  performed  by  the  Radiocommunication  Section  of  the 
standardization  ITU.  A  summary  of  the  key  features  of  FPLMTS  are: 

*high  degree  of  commonality  of  design  worldwide. 

•compatibility  of  services  within  FPLMTS  and  with  the  fixed  networks. 

•high  quality. 

•use  of  a  small  pocket  terminal  worldwide. 

Appendix  5.1  contains  a  summary  of  the  FPLMTS  project.  Appendix  5.2 
describes  the  relationship  between  FPLMTS  and  UPT. 
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TABLE  5-2  FLPMTS  Environments 


j  ENVIRONMENT 

1  CLASS 

A 

B 

C 

Business  Indoor 

« 

A 

Neighborhood  Indoor/outdoor 

B 

Home 

* 

A 

Urban  vehicular  outdoor 

« 

B 

Urban  pedestrian  outdoor 

* 

A 

Rural  outdoor 

* 

B 

Fixed  outdoor 

* 

B 

Urban  satellite 

i 

♦ 

* 

C&B 

Rural  satellite 

* 

C 

Fixed  satellite 

* 

C 

Indoor  satellite 

C 
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TABLE  5-3  Speech  Coder  Parameters 


PARAMETER 

1 

1  CLASS 

A 

B 

c 

Req 

Obj 

Req 

Obj 

Req 

Obj 

Units 

Speech  quality  without  errors 

G726 

G726 

G726 

Quality  loss,  two  radio 
interfaces  and  transcoding 

MOS 

Coder/decoder  delay  lone  way) 

5 

2 

20 

10 

100 

40 

ms 

Power  consumption 

2 

2 

20 

5 

300 

200 

mw 

Speech  coder  bit  rate 

32 

16 

16 

4 

4 

2-3 

kb/s 

Gross  speech  bit  rate 

40 

24 

32 

8 

8 

m 

kb/s 

Adaptive  bit  rate 

no 

no 

yes 

yes 

no 

no 

Voice  activity  detection 

i 

no  1 

no 

no 

yes 

yes 

yes 

Transparent  to  DTMF 

no 

yes 

no 

yes 

no 

no 

5.1.6  Mobile  Satellite  Systems 

Mobile  satellite  systems  are  currently  being  investigated  for  use  with  cellular 
and  hand-held  terminals.  The  recent  World  Administrative  Radio  Conference 
(WARC)  in  Barcelona  allocated  small  amounts  of  spectrum  in  the  L-band  (1.5  Ghz) 
and  S-band  (2.5  Ghz)  for  satellite  applications,  currently,  a  number  of  different 
satellite  architectures  are  being  discussed: 

Motorola  has  proposed  a  system  called  Iridium,  a  66  satellite  low-earth 
orbit  (LEO)  system,  which  would  provide  worldwide  communications. 
These  LEO  satellites  would  be  in  orbit  approximately  500  miles  above 
the  earth.  The  Iridium  system  would  use  a  lightweight,  hand-held 
terminal  with  a  stub  antenna. 

Loral  Space  and  Qualcomm  are  proposing  the  Globalstar  system, 
which  has  48  satellites  in  LEO  (orbiting  at  about  800  miles  above  the 
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earth).  Subscribers  would  receive  direct  satellite  services  through 
hand-held  terminals. 


TRW  is  proposing  a  system  called  Odyssey,  consisting  of  9  satellites 
at  mid-earth  orbit  (MEO).  These  satellites  would  orbit  approximately 
6000  miles  above  the  earth.  The  system  plans  to  use  the  same 
satellite  bands  as  the  previous  systems  and  may  include  Ku-band. 
Odyssey  utilizes  a  phased-array  stub  antenna  to  access  the  satellites. 

5.2  VTC  Application  of  Mobile  Radio 

At  a  meeting  on  6-17  September  1993,  Working  Party  15/1  re-appointed  a 
Rapporteur  for  Very  Low  Bitrate  Videophone.  Guidance  given  to  the  Rapporteur  by 
the  ITU  is  provided  in  Appendix  5.3.  One  of  the  requirements  is  to  develop  a 
Recommendation  for  operation  over  mobile  radio.  Several  contributions  have  been 
presented  to  the  LBC  Group  on  this  topic,  four  of  which  are  included  in  the 
appendices  listed  below. 


Appendix 


Title 


5.4  Video  Coding  in  Mobile  Networks  -  Some  Aspects 

5.5  Proposal  for  a  Generic  Data  Stream  Structure  Considering 
Current  Short-term  and  Long-term  Standardization 
Activities 

5.6  R2072:  MATV  -  The  Mobile  Audio-Visual  Terminal 

5.7  R2072:  Mobile  Audio-Visual  Terminal  (MAVT):  Liaison 
Statement  to  TSS  Study  Group  15,  Special  Rapporteurs 
Group  on  very  low  bitrate  video  coding  (Schaphorst 
Group) 


Highlights  of  these  appendices  are  provided  below. 
5.4  -  Video  Coding  in  Mobile  Network 


This  document  points  out  some  important  aspects  of  mobile  networks 
(European  Universal  Mobile  Telecommunication  Systems.  FPLMTS)  and  gives 
guidelines  for  the  development  of  video  coding  algorithms  for  the  mobile 
application.  It  is  recommended  that  the  algorithms  which  will  be  developed  by 
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MPEG-4  be  strongly  considered. 


5.5  -  Generic  Data  Stream 

In  this  document,  a  proposal  for  a  generic  data  stream  structure  is  described. 
A  common  and  flexible  data  stream  structure  is  desireable  because  there  will  be  a 
fast  development  of  services  and  demands  in  the  area  of  mobile 
telecommunications.  It  is  difficult  to  fix  a  specific  data  structure  and 
simultaneously  fulfill  future  demands  of  compatibility  with  existing  devices.  A 
flexible  data  stream  structure  can  handle  a  broad  variety  of  applications. 

5.6  -  The  European  Mobile  Audio-Visual  Terminal 

This  document  is  an  overview  summary  of  the  European  RACE  project 
R2072  which  is  designated  "The  Mobile  Audio-Visual  Terminal"  (MAVT). 

The  project  objective  is  to  find  powerful  video  and  audio  coding  algorithms  for  the 
transmission  of  moving  and  still  video  in  a  mobile  environment,  and  implement 
them  on  a  demonstrator.  This  necessitates  a  study  of  user  requirements,  network 
and  channel-characteristics,  service  definitions  and  a  general  terminal  architecture. 
The  project  will  deliver  future  algorithms  for  low  bitrate  video  (px  8k  bit/s)  and 
audio  coding,  and  a  futuristic  terminal  with  several  novel  features,  including  a 
variable  resolution  display  and  good  quality  audio.  New  proposals  for  VLSI  chips 
for  video  and  audio  coding  are  expected  from  realisation  of  the  demonstrator. 

5.7  -  R2072  Mobile  Audio  Visual  Terminal:  Channel  Coding  Aspects 

The  main  technical  objectives  of  the  MAVT  project  are  the  development  of 
robust  video  and  audio  coding  algorithms  for  transmission  of  moving  and  still  video 
and  associated  audio  in  mobile  networks.  Due  to  a  variety  of  channel  impairments 
encountered  in  case  of  a  wireless  mobile  propagation  medium  special  counter¬ 
measures  have  to  be  undertaken  to  guarantee  the  target  transmission  quality.  This 
document  discusses  error  control  strategies  under  investigation  in  the  context  of 
European  MAVT  project. 
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5.3  Government  Applications 


At  the  present  time  the  vast  majority  of  operational  cellular  radio  systems 
throughout  the  world  are  based  on  analog  technology.  Work  is  underway  to 
convert  the  systems  to  a  digital  format,  but  this  will  require  some  time  to 
accomplish.  Since  digital  operation  is  a  prerequisite  for  video  telephony, 
audiovisual  services  are  not  available  in  the  mobile  radio  environment  today.  As 
work  on  U.S.  digital  cellular  unfolds  the  primary  payload  bitrate  for  a  voice  channel 
is  8kbps.  This  low  bit  rate  relative  to  that  available  on  the  PSTN  (14.4  Kbps,  28 
Kbps)  reflects  the  fact  that  the  mobile  radio  link  is  more  complex  and  fragile  than 
the  PSTN. 

Videotelephony  work  which  has  been  accomplished  in  the  PSTN  suggests 
that  it  is  very  difficult  to  achieve  satisfactory  videophone  performance  around 
8Kbps.  Consequently  it  is  likely  that  channel  aggregation  techniques  will  have  to 
be  employed.  If  two  voice  channels  are  multiplexed  to  provide  a  combined  bit  rate 
of  16Kbps  it  would  be  possible  to  achieve  satisfactory  videotelephony  performance 
as  outlined  in  section  4.0  of  this  report.  In  Europe  the  term  PxSKbps  has  been 
coined  to  represent  this  multichannel  concept. 

When  the  mobile  radio  infrastructure  evolves  into  a  digital  form, 
videotelephony  services  will  naturally  evolve.  There  are  many  applications  in  the 
Government  community  which  could  advantageously  employ  such  services  some  of 
which  are  listed  below. 

There  are  many  instances  where  it  is  desirable  to  transmit  video  from 
a  remote  field  location  where  no  phone  exists. 

There  would  be  instances  where  it  would  be  desirable  to  access  video 
from  a  database  at  a  remote  mobile  location.  The  video  could  be  used 
to  assist  in  a  troubleshooting  mission. 

The  mobile  location  could  be  in  a  moving  platform  (aircraft,  truck, 
ship)  as  well  as  land  based. 

This  mobile  visual  capability  is  particularly  well  suited  for  use  in 
disaster  scenarios  where  agencies  like  FEMA  perform  critical  missions. 
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6.0  VIDEO  TRANSPOFTT  VIA  INTERNET 


6.1  Internet  Overview 


Internet  refers  to  a  unique  collection  of  networks,  mainly,  in  the  U.S.,  but 
also  throughout  the  world,  most  of  which  are  built  using  the  Transmission  Control 
Protocol/Internet  Protocol  (TCP/IP)  protocol  suite  and  all  of  which  share  a  common 
name  and  address  space.  Computers  on  the  Internet  use  compatible 
communications  standards  and  share  the  ability  to  contact  each  other.  Users  of 
the  Internet  communicate  mainly  via  electronic  mail  (e-mail),  via  Telnet,  a  process 
that  allows  them  to  login  to  a  remote  host,  and  via  the  File  Transfer  Protocol  (FTP), 
a  protocol  that  allows  them  to  transfer  information  on  a  remote  host  of  their  local 
site.  See  Figure  6.1 . 


Figure  6.1  Conceptual  Structure  for  Internet  Protocol 


Currently,  there  are  over  100  countries  that  have  some  access  to  the 
Internet,  almost  39,000  networks  assigned  unique  IP  network  numbers,  almost  one 
million  hosts  known  to  the  domain  name  system,  and  at  least  3,500,000  users 
worldwide. 

The  Internet  exists  to  facilitate  the  sharing  of  resources  among  participating 
organizations,  which  include  government  agencies,  educational  institutions,  and 
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private  corporations;  to  promote  collaboration  among  researchers;  and  to  provide  a 
testbed  for  new  developments  in  networking. 

The  Internet  is  a  cooperating  group  of  independently  administered  networks. 
Each  component  network  on  the  Internet  has  its  own  administrative  body,  its  own 
policies,  and  its  own  procedures  and  rules.  There  is  no  central,  overseeing 
authority  for  the  whole  of  the  Internet.  However,  certain  government  agencies 
have  traditionally  been  prominent  in  setting  policy  that  is  followed  throughout  the 
Internet.  Today  important  policy  decisions  come  from  the  National  Science 
foundation  (NSF),  administrator  of  the  National  Science  Foundation  Network 
(NSFNET),  and  from  the  Defense  Information  Systems  Agency  (DISA), 
administrator  of  the  Defense  Data  Network  (DDN). 

In  addition  to  influential  government  agencies,  a  strong,  mostly  voluntary, 
coalition  of  technically  knowledgeable  individuals  guide  the  development  of  the 
Internet.  Innovations  that  upgrade  the  technical  quality  of  the  Internet  are  usually 
worked  out  cooperatively  by  the  technical  community  working  together  under  the 
auspices  of  a  group  called  the  Internet  Architecture  Board  (lAB).  The  lAB  has 
recently  been  included  as  part  of  the  structure  of  the  Internet  Society  (ISOC). 

There  is  a  hierarchy  of  Task  Forces,  Areas,  and  Working  Groups  under  the  lAB  that 
address  technical  problems  and  develop  solutions.  Eventually,  solutions  are  agreed 
upon  by  the  Internet  community  and  the  lAB  recommends  they  be  implemented.  In 
this  way,  new  additions  to  the  TCP/IP  suite  of  protocol  standards  are  developed, 
tested,  recommended,  and  implemented. 

ARPANET 


The  ARPANET  does  not  exist  any  more,  but  we  include  its  description 
because  you  will  sometimes  hear  the  term  ARPANET  used  interchangeably  with  the 
term  Internet.  The  ARPANET,  the  predecessor  of  today's  Internet,  was  the  first 
packet-switched  network  to  connect  heterogeneous  computers.  That  is, 
computers  of  different  types  could  exchange  information  for  the  first  time  because 
of  the  network  protocols  developed  for  the  ARPANET. 

In  1984,  the  ARPANET  was  split  into  two  networks:  the  ARPANET  for 
research  oriented  activities,  and  the  Defense  Data  Network  (DDN)  for  military 
operational  activities.  The  DDN  still  exists  as  one  of  the  Internet  networks;  its 
MILNET  network  provides  unclassified  operational  support  to  military  users.  The 
ARPANET  itself  was  phased  out  in  1990  in  favor  of  the  more  advanced  NSFNET 
backbone. 
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FIGURE  6.2 
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NSFNET 


The  National  Science  Foundation  (NSF)  sponsors  the  main  research  and 
education  backbone  of  the  Internet  today.  This  network  is  called  the  NSFNET. 

The  NSFNET  is  a  hierarchical  network  of  networks.  At  the  highest  level  is  the 
backbone.  At  first  ,  the  NSFNET  backbone  connected  supercomputer  centers,  but 
the  NSFNET  evolved  to  interconnect  a  group  of  networks  commonly  called  "mid- 
level"  networks. 

MILNET 


The  MILNET  was  established  as  a  separate  network  in  1984  when  it  was 
partitioned  off  of  the  ARPANET.  This  network  is  supported  by  the  Defense 
Information  Systems  Agency  (DISA)  of  the  Department  of  Defense.  The  MILNET  is 
the  unclassified  component  of  the  Defense  Data  Network  (DDN).  There  are 
currently  six  gateways,  called  "mailbridges,"  that  link  the  MILNET  with  the 
NSFNET/Internet. 

INTERNET  ORGANIZATION 

Figure  6.2  is  an  organization  chart  of  the  Internet  Society  showing  its 
relationship  to  the  Internet  Standards  and  Research  Infrastructure  which  is 
illustrated  in  Figure  6.3. 

Experimented  work  in  the  transmission  of  audio  and  video  over  Internet  is 
being  performed  within  the  Transport  and  Service  Area  (TSV).  Within  the  TSV  are 
the  two  related  Work  Groups  listed  below. 

Audio/Video  Transport  (AVT) 

The  Audio/Video  Transport  Working  Group,  chaired  by  Stephen  Casner,  USC, 
was  formed  to  specify  experimental  protocols  for  real-time  transmission  of  audio 
and  video  over  UDP  (User  Datagram  Protocol)  and  IP  multicast.  The  focus  of  this 
Group  is  near-term  and  its  purpose  is  to  integrate  and  coordinate  the  current  AV 
transport  efforts  of  existing  research  activities.  No  standards-track  protocols  are 
expected  to  be  produced  because  UDP  transmission  audio  and  video  is  only 
sufficient  for  small-scale  experiments  over  fast  portions  of  the  Internet.  However, 
the  transport  protocols  produced  by  this  Working  Group  should  be  useful  on  a 
larger  scale  in  the  future  in  conjunction  with  additional  protocols  to  access 
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network-level  resource  management  mechanisms.  Those  mechanisms,  research 
efforts  now,  will  provide  low-delay  service  and  guard  against  unfair  consumption  of 
bandwidth  by  audio/video  traffic. 

The  AVT  Working  Group  may  design  independent  protocols  specific  to  each 
medium,  or  a  common,  lightweight,  real-time  transport  protocol  may  be  extracted. 
Sequencing  of  packets  and  synchronization  among  streams  are  important 
functions,  so  one  issue  is  the  form  of  timestamps  and/or  sequence  numbers  to  be 
used.  The  Working  Group  will  not  focus  on  compression  or  coding  algorithms 
which  are  domain  of  higher  layers. 

Multiparty  Multimedia  Session  Control  (MMUSIC) 

The  purpose  of  the  MMUSIC  Working  Group  is  to  develop  an  infrastructure 
to  support  teleconferencing  over  Internet.  Multimedia  session  control,  defined  as 
the  management  and  coordination  of  multiple  sessions  and  their  multiple  users  in 
multiple  media  (e.g.,  audio,video),  is  one  component  of  the  infrastructure.  The 
Multiparty  Multimedia  Session  Control  Working  group  is  chartered  to  design  and 
specify  a  protocol  to  perform  these  functions. 

The  protocol  will  provide  negotiation  for  session  membership,  underlying 
communication  topology  and  media  configuration.  In  particular,  the  protocol  will 
support  a  user  initiating  a  multimedia  multiparty  session  with  other  users  over  the 
Internet  by  allowing  a  teleconferencing  application  on  one  workstation  to  explicitly 
rendezvous  with  teleconferencing  applications  running  on  remote  workstations. 
Defining  a  standard  protocol  will  enable  session-level  interoperability  between 
different  teleconferencing  implementations. 

The  focus  of  the  Working  Group  is  to  design  a  session  negotiation  protocol 
that  is  tailored  to  support  tightly-controlled  conferences.  The  current  protocol 
carries  primarily  loosely-controlled  sessions,  i.e.,  sessions  with  little  to  no 
interaction  among  members  and  with  no  arbitration  facility,  security,  or 
coordination  of  quality-of-service  options  for  time-critical  media. 

The  main  goal  of  the  Working  Group  will  be  to  specify  the  session  control 
protocol  for  use  within  teleconferencing  software  over  the  Internet.  The  Working 
Group  will  focus  on  the  aspects  of  the  session  control  problem  that  are  well 
understood,  while  keeping  an  eye  on  evolving  research  issues.  Toward  this  end, 
the  Working  Group  has  made  an  inventory  of  existing  conferencing  systems  and 
their  session  control  protocols.  The  Working  Group  will  document  the  requirements 
of  the  existing  prototypes  as  a  basis  for  the  protocol  development.  The  Working 
Group  will  iteratively  refine  the  protocol  based  on  implementation  and  operational 
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experience. 


6.2  Video  Coding  Products 

Teleconferencing  experiments  on  Internet  have  been  performed  using  three 
different  video  coding  software  packages  installed  on  Workstation  platforms.  The 
software  packages  are  briefly  described  below. 

PICWIN  bv  Bolt  Beranek  and  Newman 

PictureWindow  (PICWIN)  is  a  software  package  that  allows  workstation 
users  to  hold  video  conferences  over  IP  networks.  BBN's  PictureWindow  system 
brings  multiparty,  wide-area  video  conferences  directly  onto  your  workstation 
screen  with  minimal  additional  hardware.  PictureWindow  provides  personal  video 
conferencing  capability  through  the  use  of  BBN  software,  Sun's  inexpensive 
VideoPix  frame-capture  board,  and  a  video  camera  on  your  existing  color 
SPARCstation. 

PictureWindow  compresses  and  decompresses  video  entirely  in  software, 
transmits  it  using  standard  IP  protocols,  and  displays  it  in  multiple  windows  under 
OpenWindows  or  the  XWindow  System.  It  operates  over  Internet  Protocol  (IP) 
based  wide-area  networks,  and  it  can  be  used  in  either  point-to-point  or  multicast 
modes. 

PictureWindow  video  windows  measure  320x240  pixels  with  16  levels  of 
gray.  Refresh  rate  depends  upon  system  and  network  load,  but  it  is  typically 
between  3  and  6  frames  per  second. 

PictureWindow  sends  compressed  video  in  UDP/IP  datagrams  and  functions 
in  both  local  and  wide-area  network  environments.  The  actual  network  bandwidth 
used  by  any  one  conferee  depends  on  the  amount  of  motion  in  the  supplied  video, 
and  the  image  quality  desired  by  the  viewers.  In  two-way  conferences,  each 
conferee  can  selectively  adjust  the  equality  and  compression  parameters  for  the 
image  they  are  viewing.  PictureWindow  functions  best  when  network  paths  with 
at  least  256  kilobits/second  are  available.  Nevertheless,  network  paths  as  slow  as 
56  kilobits/second  can  be  used  by  decreasing  the  frame  rate  and  increasing  the 
acceptable  image  error.  More  information  on  PICWIN  is  provided  in  Appendix  6.1. 
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NV  bv  Xerox 


The  NV  software  package  encodes  frame  differences  using  wavelet  coding 
over  an  8  X  8  pixel  array.  Motion  compensation  is  not  employed.  At  the  default 
bitrate  of  1 28  Kbps  the  picture  rate  is  3  frames/second.  Picture  resolution  is  320  x 
240  pixels. 

IVS  bv  Inria 

Inria  is  a  research  institute  in  France  which  has  developed  the  IVS  software 
package  which  is  based  on  the  H.261  coding  algorithm.  A  picture  frame  rate  of  1- 
2  frames/second  has  been  achieved  in  experiments. 

CUSEEME  bv  Cornell  University 

Cornell  University  has  developed  a  software  video  coding  software  package 
which  is  suitable  for  the  Macintosh  PC  as  well  as  the  Sun  Workstation. 

6.3  Government  Applications 

The  Internet  is  now  used  to  provide  E-Mail  service  to  millions  of  users 
throughout  the  world.  The  primary  use  for  Internet  is  the  provision  of  a  store-and- 
forward  message  service  as  opposed  to  an  interactive  conversational  service 
(speech,  video).  Nevertheless,  Internet  is  becoming  so  pervasive  and  ubiquitous 
that  it  is  natural  to  consider  the  extension  of  Internet  to  provide  videotelephony 
services. 

Since  E-Mail  is  a  personalized  service  it  is  natural  to  consider  the  use  of 
Internet  for  head-and-shoulders  videophone  applications  as  opposed  to  the 
videoconferencing  application  from  a  conference  room.  However,  as  desktop 
multimedia  workstations  become  more  prevalent  and  video  bridges  (Multiport 
Control  Unit)  become  more  capable,  video  conferences  (like  audio  conferences 
today)  will  become  more  desk  oriented  rather  than  conference  room  oriented. 
Consequently,  in  time,  Internet  could  be  considered  to  provide  video  conferencing 
service  as  well  as  videophone  service. 

At  the  present  time  the  use  of  Internet  to  provide  videotelephony  services 
must  be  considered  very  speculative.  It  may  never  have  a  serious  impact  as  a 
communications  medium  relative  to  other  media  such  as  switched  56kbps,  N-ISDN, 
PSTN,  and  LANSWANS.  Reasons  for  this  viewpoint  are  listed  below. 
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Typical  transmission  bit  rates  employed  for  Internet  are  1 28  Kbps  for 
video  and  64  Kbps  for  speech.  The  Internet  Infrastructure  does  not 
support  these  rates  in  high  volume. 

The  protocol  structure  Is  not  well  suited  to  low  delay  interactive 
services. 
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7.0  CONCLUSIONS  AND  RECOMMENDATIONS 


Video  teleconferencing  is  becoming  a  very  important  service  throughout  the 
government  community.  At  the  present  time  the  traditional  transport  media  are 
switched  56Kbps  channels  and  fractional  Tl  channels.  In  this  report  four 
alternative  transport  media  for  the  VTC  application  have  been  examined,  and  an 
overview  of  the  result  is  provided  in  Table  7-1. 

TABLE  7-1 
Overall  Summary 


TRANSPORT 

MEDIUM 

VTC  TERMINAL 

EQUIPMENT 

GOVERNMENT 

APPLICATION 

LAN/MAN 

Several  mature 
configurations  exist: 
Ethernet,  Token 

Ring,  FDDI,  ATM 

Many  VTC  terminals 
are  available;  some 
meet  H.261;  H.32Z 

standardization  is 

underway 

VTC  via  these 

media  are  very 
important  to  the 
government; 

mobile  radio  is  in 

the  future 

PSTN 

Ubiquitous,  mature; 

new  modem 
technology  increases 
the  potential  for  VTC 

Several  proprietary 
products  exist;  ITU 
standard  being 
developed 

MOBILE 

RADIO 

Not  ready  for  VTC 
applications  until 
conversion  to  digital 
operation  gains 

momentum 

No  products  exist; 
Europe  is  planning  a 
VTC  product;  ITU 
standard  is  being 
developed 

INTERNET 

Used  primarily  for  E- 
Mail.  Existing 

Internet  not  well 
suited  for  high 
volume  of  VTC 

traffic 

Only  software 
products  are 
employed;  one  is 
commercially 

available 

This  experimental 
work  may  be 
applicable  to 

future  WANs 

such  as  NREN 

Since  there  is  considerable  promise  for  the  use  of  these  media  for  VTC 
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service  in  the  government  community,  it  is  recommended  that  the  government 
actively  participate  in  the  process  of  stimulating  technology  advancement  and 
standards  development  in  the  following  specific  areas. 

H.32Z;  conversion  of  H.320  to  LAN  operation 

H.32P;  development  of  a  videophone  standard  for  the  PSTN  and 
mobile  radio  environment 

development  of  digital  mobile  radio  standards 

further  analysis  of  LAN/MAN  technology  and  related  VTC  terminal 
products  to  provide  guidance  for  government  deployment. 
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APPENDIX  3.1 


EXAMPLES  OF  COMMERCIAL  PRODUCTS 
FOR  PROVIDING  VTC  SERVICES  OVER  LANs 


PictureWindow  Desktop  Video  Conferencing 


Note:  Because  PictureWindow  uses  the  MIT-SHM  option  ofX  Windows,  you  MUST  run 
PictureWindow  on  the  same  workstation  as  your  X  server.  You  cannot  run  picwin  on  a  remote 
computer  and  use  an  X  terminal  or  other  X  server  to  view  the  results. 

To  conduct  conferences  with  workstations  other  than  your  own,  you  will  need  to  be  con¬ 
nected  to  a  TCP/IP  network,  and  your  workstation  should  be  configured  with  a  unique  IP 
address  on  that  network.  Your  system  or  network  administrator  should  be  able  to  help  you 
if  you  are  uncertain  regarding  this  requirement.  Most  Sun  workstations  arc  connected  to 
networks  of  some  type  (usually  Ethernet)  and  are  configured  for  TCP/IP  operation  as  the 
default.  You  can  verify  your  networking  capabilities  by  consulting  the  Sun  System  &  Net- 
work  Managers  Guide  supplied  with  your  workstation  or  your  local  network  administrator. 

If  you  are  setting  up  your  workstation  for  the  first  time,  a  configuration  using  the  Sun- 
supplied  GENERIC  configuration  of  SunOS  4.1.1,  OpenWindows  2.0,  and  the  VideoPix  dri¬ 
ver  are  sufficient  to  support  PictureWindow. 


VIS-A-VIS  V  ID  E  O 


Full  Motion  Vidoo  on  your  PC 

VIS-A-VIS  Video  is  desktop  conferencing  software 
that  ddivers  full  motion  video  information  through 
your  PC.  Since  it  runs  on  your  PC  it  is  there 
whenever  you  need  it,  and  it  combines  all  the  op¬ 
tions  and  benefits  of  audiographics  conferencing 
and  fun  motion  video  conferencing  at  the  desktop  or 
conference  room  through  a  sin^e  PC. 

PuOy  imtgrartod  Desktop  ConfsrsnelfiQ 

VIS-A-VIS  Video  combines  the  shared  space  envi¬ 
ronment  with  video  telephony  on  the  same  PC. 
Users  can  share  graphic  information  and  annotate 
in  the  shared  screen  at  the  same  time  as  they  can 
see  and  hear  the  person  on  the  other  end  In  full 
motion  video. 

VIS-A-VIS  Video  does  not  restrict  desktop  con¬ 
ferencing  to  users  with  ftill  motion  video.  Other 
VIS-A-VIS  users  can  communicate  with  VIS-A-VIS 
Video  users,  but  without  the  full  motion  inteiface. 


Shnpls  Controls  For  Ease  of  Uss 

*nie  VIS-A-VIS  video  screen  Is  set-up  so  that  the  left 
80%  of  the  monitor  contains  the  shared  screen,  with 
the  user  controls  and  the  lull  motion  video  window 
on  the  right  20%  of  the  screen.  A  set  of  Function 
selection  controls  altow  any  two  of  the  Video,  Fold¬ 
ers.  Pens,  or  I/O  functions  to  be  open  at  any  one 
time  in  two  open  miniature  windows, 

1110  "Video"  control  overlays  an  image  from  an  NTSC 
input  source  (Full  Motion  Video  Codec,  Camcorder, 
Camera  or  VCRl  Into  the  miniature  full  motion  video 
window.  The  full  motion  video  image  can  also  be 
expanded  into  the  shared  space  area  of  the  screen 
or  "zoomed"  to  a  full  screen  image.  A  "Re¬ 
mote /Local"  feature  enables  users  to  view  the  full 
motion  video  image  being  transmitted  to  them  from 
a  remote  VIS-A-VIS  Video  site,  or  the  image  from 
their  own  site. 

The  "Folders”  control  provides  four  folders  and  a 
wastebasket  fi*om  which  slides  can  be  stored,  ma¬ 
nipulated,  and  dragged  to  the  shared  space  for 
display  in  a  conference. 


The  Tens”  control  gh^es  users  a  selection  of  3  colour 
pens,  a  highlighter,  an  eraser,  a  whiteout.  or  a 
kejrboard  for  annotating  in  the  shared  space. 

The  1/0”  control  displays  a  set  of  icons  showing 
which  Input/ Output  devices  are  available  at  your 
VIS'A'VIS  site.  Ihese  can  include  camera  image 
capture,  document  scanner  input  or  printer  output. 

Simpis  Full  Motion  Conversion 

VIS-A-VIS  Video  is  based  on  the  standard  VIS-A-VIS 
platfonn  and  I/O  devices,  and  onh'  requires  the 
addition  of  a  Vidcologlc  DVA  card  or  a  Truevision 
Bravado  board  to  provide  the  NTSC  overlay  (full 
motion)  function  on  the  PC  screen. 

VIS-A-VIS  Video  works  with  widely  available  video 
codecs,  and  can  be  set-up  to  run  in  point-to-point 
connection  through  an  R5232  interface  on  the 
codecs. 

The  VIS-A-VIS  Video  Benefits 

□  Low  cost  video  conferencing  on  a  PC 

□  Replaces  expensive  and  time  consuming  dis¬ 
tance  iace-to-face  meetings 

□  Offers  effective  real-time  interaction  between 
people  at  different  locations 

□  Facilitates  fast,  effective  decision  making 


The  VIS-A-VIS  Video  Advantage 

□  Full  motion  video  information  provided  by  a 
standard  video  codec  connected  to  video  net¬ 
work  services  such  as  56Kbps,  ISDN  or  frac¬ 
tional  T1 

□  Offeis  full  mtegiatlon  of  video  and  data  on  your 
PC 

□  Provides  access  and  control  of  various  multime¬ 
dia  I/O  devices  such  as  document  scanner, 
camera,  laser  printer  and  electronic  whiteboard 

□  Offers  standard  data  network  connectivity  sup¬ 
port  of  VIS-A-VIS  including  data  bridging 

Numsrous  Appileattons 

VIS-A-VIS  Video  offers  numerous  applications  for 

business,  government  and  education. 

□  Project  control  and  management 

□  Manufacturing  review 

□  Design/ development  review 

□  Telecommuting 

□  Distance  education 

□  Pull  motion  video  conferencing 

□  Medical  consultation  and  training 


For  more  Information,  contact 

VIS-A-VIS  Sales  &  Marketing.  275  Matheson  Blvd  East.  Mississauga.  ON,  Canada  L4Z  1X8 
Phone  (416)  890-2773  FAX  (416)  890-6789  Tbll  Free  1-800-263-9673 


Cl/ll 


Basic  Configuration 

PC  Requlrwnonts:  IBM  PS/2,  IBM  PC/AT  or  compatible,  hard  drive  (min.  20  MB),  SMB  RAM 

(4MB  High  Res.).  Wacom  tablet  (or  any  compatible  tablet  and  stylus)  or 
Microsoft  mouse  or  compatible,  and  MS-DOS  V3.3  or  later. 

(Note;  MS-DOS  S.O  recommended). 

Monitors;  VGA  Monitor— 1 6  ootors,  640  x  480  pixel  resolution,  or 

VGA  Monitor— 256  cotors,  640  x  480  pixel  resolution. 


Multimedia  Options 


High  Resolution: 


Scanner; 

Camera: 


Printer; 


Whiteboard: 


Video: 


VIS-A-VIS  supports  1024  X 1024  pixels,  i6-blt  color  high  resolution  multisync 
monitor  and  Imagraph  PM1010  card  and  cable.  An  8-blt  VGA  card  ie  also  re¬ 
quired  tor  VGA  support  (Non-interlaced  32.5  to  64KHz).  VIS-A-VIS  has  been 
tested  with  NEC,  Hitachi  and  Taxan  AGC  monitors. 

(Note:  MCA  High  Resolution  card  not  available.) 

VIS-A-VIS  supports  the  CANON  1X30  flat  bed  and  HP  ScanJet.  Scanner  in¬ 
terface  cards  are  required. 

VIS-A-ViS  supports  any  RGB/NTSC/PAL  input  device  like  the  JVC  Camera, 
Camcorder,  or  the  ELMO  EV-308  Scanner.  Your  PC  requires  a  full  size  16- 
bit  slot  for  a  Targa-16  Card  to  drive  these  devices. 

ViS-A-ViS  supports  the  HP  Laserjet  II.  IIP  and  Series  III  laser  printers  or  any 
printer  that  supports  HP's  Laserjet  Emulation.  There  are  tw»ro  ways  to  print 
documents  from  VlS-A-VlS— using  a  JLaser  Card  or  through  the  parallel  port 
on  the  PC.  The  JLaser  Card  prints  an  image  in  15-20  seconds.  Parallel 
printing  takes  up  to  10  times  longer.  The  JLaser  Card  requires  a  fuO  size  16- 
bit  slot  in  your  PC. 

VIS-A-VIS  supports  the  SMART  Etectronic  Writing  Board  with  an  active  area 
resolution  of  3,500  by  2,600  pixels  and  an  active  display  area  of 
120cm  X  90cm.  A  projection  system  (such  as  an  LCD  panel  and  an  overhead 
projector)  projects  the  ViS-A-ViS  Image  onto  the  board. 

VIS-A-VIS  supports  full  motion  video  using  the  Truevision  Bravado  board. 
Any  codec  providing  NTSC  output  can  be  used  with  VIS-A-VIS,  It  has  been 
tested  with  NEC,  CLI  and  Picturetel  codecs,  as  well  as  a  PC  codec  on  a  card 
from  VistaCom. 

(Note:  MCA  High  Resolution  card  not  available.) 


Note:  VIS-A-VIS  provides  support  for  mutlimedia  options  at  an  additional  cost.  Each  VIS-A-VIS  workstation 
can  be  configured  according  to  the  users  individual  needs. 


WORLDUNX 


Communication  Options 
Polnt>to>Polnt: 

VIS-A-VIS  can  communicate  point-to-point  using  synchronous,  asynchronous.  Netbios  or  TCP/IP 
communications. 

Asynchronous;  Each  PC  requires  a  Hayes  or  compatible  asynchronous  modem  (@  2,400  to 
19.200bps) 

Synchronous:  Each  PC  requires  an  EICON  Card  with  X.25  Network  Access  Softw^e  and  a 

synchronous  modem  ((g)  2,400bps  to  64Kbps).  Note:  your  PC  requires  an  6- 
bit  sbt  for  the  EICON  Card. 

Netbios  LAN:  Requires  a  Local  /Vea  Network  card  running  a  Netbios  layer  (acquire  from 

your  local  LAN  vendor). 

TCP/IP  LAN:  Uses  PC/TCP  by  FTP  Software  (release  2.05  or  later),  or  Pathway  Access  by 

Wollongong  (release  2.0  or  later). 

Multipoint: 

VIS-A-VIS  can  communicate  multipoint  over  a  LAN,  packet-switched  network,  or  the  VIS-A-VIS  Data 
Bridge. 

The  VIS-A-VIS  Data  Bridge  Is  required  for  muttlpoint  communications,  or  when  you  are  communi¬ 
cating  between  different  communication  networks  (e.g,,  synchronous  to  asynchronous  communica¬ 
tion). 

The  Data  Bridge  supports  up  to  8  simultaneous  conferences  wKh  a  total  of  32  participants.  A  Data 
Bridge  Is  not  necessarily  required  for  multipoint  communication  over  a  ^N  or  packet-switched 
networks,  but  performance  can  be  impacted  by  the  number  of  users,  traffic  and  line  speed,  and  a 
Data  Bridge  should  be  considered. 

PC  Requirements;  IBM  PC/AT  or  compatible,  recommend  20MHz+,  2MB  RAM,  40MB+  hard 
drive,  monochrome  monitor  and  card  and  MS-DOS  V3.3  or  later. 

Appropriate  synchronous,  asynchronous  and  LAN  Interface  cards  are  required. 

Asynchronous:  Requires  a  Digiboard  Sght  Port  (l.e.,  8  users)  Asynchronous  Card.  Your  PC 
requires  a  full  size  1 6-bit  slot. 

Synchronous:  Requires  an  EICON  Four  Port  (4  users)  Card  with  x.25  Network  Access  soft¬ 

ware.  Your  PC  requires  a  full  size  S-bit  slot. 

LAN:  Netbios  and  TCP/iP  LAN  requirements  are  the  same  as  those  shown  under 

•Point-lo-Poirrt"  section  above. 


For  more  Informatton,  contact 

VIS-A-VIS  Sales  &  Marketing,  27S  Matheson  Blvd  East,  Mississauga.  ON,  Canada  L4Z 1X8 
Phone  (416)  890-2773  FAX  (416)  890-6789  Toll  Free  1-800-263-9673 
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Communique!  System  Requirements _ 

SuBDorted  Platfoms:  All  Sun  Microsystems*  servers  and  worksutions. 

All  SPARC^-based  servers  and  workstations. 

Hew'lett-Packard  Apollo  9000  Scries  700  workstations. 

Contact  InSoft  for  availability  on  other  UNIX /RISC  platforms. 


Recommended  Workstation  Configuration:  32  Mb  RAM. 

5  to  10  Mb  of  temporary  disk  space. 

Full  Color  Display  recommended.  _ 

Minimum  Software  Requirements:  SunOS  4.1  .X  with  System  V IPC  facilities  in  system  kernel 

or  Solaris  2.X. 

Open  Windows*  3.0 

HP/UX  9.0.1  or  above  and  HP-VUE  3.0. 

50  Mb  swap  space/ 60  or  more  preferred. 


Communications/Network  Requirements 

Contact  InSoft  for  specific  configuration  and  bandwidth  requirements.  _ 


Modem;  9600  baud  minimum 

to  run  Communique!  without  video  and  audio. 


Local  Area  Network:  Any  TCP  /  IP  or  Ethernet  based  network. 


Wide  Area  Network  Services:  ISDN,  SME>S,  Frame  Relay,  Switched  56,  FDDI,  ATM 

56  Kb  to  T1  and  up. 


CommuniquelTV  Support 


For  Real  Tunc,  Full  Motion  Color  Video  Features 


Hewlett-Packard  Series  700  Workstations:  HP  VideoLive  card 

ttsing  NTSC,  PAL  and  SECAM  signal  formats. 


Sun  Workstations:  RasterOps  SPARC  TV  II  card 

using  NTSC,  PAL  and  SECAM  signal  formats. 

Sun  VideoPix* 

SBus  card  using  NTSC  and  PAL  signal  formats. 

Parallax  Graphics®  X\^deo-245V 

SBus  card  using  NTSC,  PAL  and  SECAM  signal  formats. 


Let  Communique!  productively  and  profitably  change  the  way  you  do  business. 
Call  today  for  complete  details  and  pricing  -  717-730-9501. 


InSoft 

Revolutionizing  The  Way 
You  Do  Business. 


InSoft,  tnc..  Executive  Park  We$t  One,  Suite  S07,  4718  Old  Gettysburg  Road,  Mechanicsburg,  PA  17055  Pax:  717-730-9504  omoil:  infoOinsoft.com 
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Personal  Viewpoint "  Produd  Brief 


Overview 

LAN/WAN  Desktop  Videoconferencing 

PCTSOnal  viewpoint  provides  desbop  videoconferencing 
copobilify  to  your  personol  computer.  Operating  under 
Microsoft  Windows 3.1  in  o  386  or  486  Personol 
Contputer,  the  Personal  Viewpoint  is  a  single  ISA 
expansion  board.  The  board  allows  you  to  videoconference 
via  your  existing  Ethernet  or  Token  Ring  IAN.  Using  the 
TCP/jP  tronspoft  protocol,  enables  Personal  Viewpoint  to 
communicote  vio  bridges  ond  routers.  Personal  Viewpoint 
uses  Viewpoint  System's  patented  CPV'^'^  (Compressed 
Pocket  Video)  technology  to  provide  variable  bit  rate,  packet 
bosed  communicoiions  designed  to  minimize  IAN  tragic. 
The  video  disploy  is  full  color,  up  to  30  frames  per  second 
ond  completely  sizable  from  on  icon  to  full-screen.  TTte 
processing  power  required  for  video  compression  ond 
decompression  is  contained  on  the  Personal  Viewpoint 
board.  Personal  Viewpoint  will  disploy  incoming  video 
even  while  you  are  running  other  Windows  opplicotions. 
keokime  interactive  video*  conferencing  combined  with 
other  colioborotlve  computing  or  groupwore  software 
products,  provide  produciive  electronic  meeting  copablliry. 

Product  Highlights 

Personal  Viewpoint  performs  reoklme  compression, 
decompression,  display  and  packetizoiior.  of  live  video  for 
transport  over  locol  and  wide  area  pocket  networb. 

Copcbllities  include: 

•  Reakime  video  compression  &  decompression. 

•  Scobble  color  video  display  under  Windows'^  3.1. 

•  Frome  rote  of  up  to  30  frornes  per  second. 

•  TCP/IP  transport  via  Ethernet  or  Token  Ring. 

•  Vflrioble  Bit  Rate  Codec  with  Dynamic  Burst  Control. 

•  less  itQT)  70ms  of  lotency. 

Background  Display  Copability 

Personal  Viewpoint  will  display  incoming  video  even 
while  it  IS  not  the  odive  opplication.  This  ollows  you  to  work 
with  0  word  processing  document  or  o  spreoefsheet  while 
you  continue  your  videoconference.  Any  Window's 
application  including  Client/ Server  applicotions  can  be 
occessed  during  the  videoconference. 


Visual  Caller  ID 

Upon  receipt  of  o  conference  request,  Personal  Viewpoint 
user  interface  software  will  alert  you  with  a  diolog  box 
indicating  the  name  of  the  caller.  You  have  the  option  of 
occepting  or  rejecting  the  coll.  In  oddition,  you  may  choose 
to  preview  the  colling  party  to  visually  confirm  identity.  After 
preview,  you  ogain  hove  the  option  of  occepting  or 
rejecting  the  conference  request. 

Ouf  of  Band  Audio 

Due  to  the  extremely  low  latency  (less  than  70ms)  in  the 
Personal  Viewpoint  video  compression,  audio  can  be 
tronsmitted  out  of  band,  while  maintolning  synchronization 
with  the  video.  This  ollows  fhe  audio  to  be  transmined  over 
existing  telephone  equipment. 

Key  Chat 

Occasionally  you  may  accept  a  videoconference  request 
while  you  ore  olreody  engaged  in  o  telephone 
cenversotion.  The  Key  Chof  feature  allows  you  to 
communicate  with  me  video  colie r  via  the  keyboard. 

Video  Mute 

Video  Mute  functions  much  the  some  as  audio  mute  on  your 
telephone.  When  Video  Mute  is  selected  your  video 
transmission  stops.  When  Video  Mute  is  deselected  video 
transmission  resumes. 

Server  Mode 

Eoch  Personal  Viewpoint  defaults  into  server  mode  upon 
Windows  startup.  There  ore  several  options  with  regard  to 
ificoming  conference  completion.  The  system  con  be 
ccnfjqurM  to  require  you  to  confirm  all  conference  requests. 
Listea  known  users  or  selected  users  from  this  list  oon  ^ 
ollowed  outomatic  coll  completion.  The  system  con  also  be 
configured  for  automatic  completion  of  oil  conference 
requests.  This  lecture  is  especially  useful  when  you  will  be 
eway  from  your  desk  for  on  extended  period  of  lime.  Audio 
collers  routed  to  your  Voicemail  can  visuolly  oscertoin 
whether  you  ore  on  fhe  phor>e  or  away  from  your  desk. 

VHnSock  CompUont 

Personal  Viewpoint  requires  o  PC  TCP/)P  stock.  The 
system  operates  with  any  PC  TCP/IP  stock  which  supports 
the  Windows  Sockets  API. 
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Personal  Viewpoint "  Product  Brief 


Dynamic  Burst  Central 

Personctl  Viewpoint  o  varbble  bit  rale  codec.  The 
maximum  burst  rate  t$  configurable  from  64  Kbps  to  768 
Kbps.  If  the  network  becomes  congested,  this  can  be 
dynamicolly  odjusted,  with  no  interruption  to  ongoing 
videoconferences.  The  maximum  burst  rote  at  each  end  of  a 
videoconference  can  be  configured  differently. 

Color  Micro*  Camera 


Specjficafierts 

Form  focton  1 3.-4'  x  4.2' 

{340mnn  x  107mml 

System  requirements:  lntel386''*^X  25AAHz 

or  better 

Board  interface  connections: 

RGB  video  output:  DB-15  for  VGA  or  muhi- 

sync  monitor 


The  Personal  Viewpoint  Color  Micro  Camero  is  a  low 
lux,  high  resolution,  color  video  camera,  in  o  very  smol!  form 
foctor.  The  camerc  is  designed  to  be  ploced  on  lop  of  your 
VGA  monitor  end  monualiy  pivots  to  odiust  for  monitor 
height.  The  camerc  con  be  daactivoted  for  privocy.  The 
video  output  of  the  comero  is  NTSC  composite  video.  A 
user  supplied  NTSC  composite  camerc  may  be  used  in 
place  of  me  Color  Micro  Camera, 


VGA  feature  connector; 
Video  input: 

Video  Resolution: 

Power  consumption: 


VESA  Standard 

RCA  female  connector 
NTSC  composite 

256K  X  200V 

Nominal 

7k 

■»-12V  .175A 

-12V  .05A 


LANIWAN  Desktop  Videoconferencing 


Equipment  Approvals: 


FCC  Class  B 


3: 


Elhernef 


Personal  Viewpoint  is  an  !SA 
PC  exponsion  board  thof  provides 
reokime  motion  video  compression 
and  decompression  for  desktop 
video  conferencing  via  pocket 
nelworb.  The  compressed  pocket 
video  con  be  transmitted  over 
Ethernet,  Token  Ring,  Frame  Reby 
or  FDDI. 

Personal  Viewpoint  operotes 
under  Microsoft®  Windows^  3. 1 
with  TCP/IP  os  the  transport 
protocol.  The  end-user  price  for  the 
Personal  Viewpoint  with  color 


comero  Is 


$1,995. 
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FOR  IMMEDIATE  RELEASE 


CONTACT :  Richard  Penn 

2247  Wisconsin  Street 
Suite  no 
Dallas,  Texas  75229 
TEL  214-243-0634 
FAX  214-243-0635 

Viewpoint  Systems  Introduces  Personal  Viewpoint™ 

Desktop  Video  Conferencing  for  Corporate  LANAVAN  Networks 

Editor's  Summary 

\^ewPoint  Systems,  Inc.,  of  Dallas.  Texas  has  announced  a  new  desktop  video  conferencing 
system  called  Personal  Viewpoint  that  operates  over  existing  PC  Local  Area  and  Wide  Area 
Networ^.  The  current  release  operates  under  Microsofti&Windows’^S.  1.  A  version  that  is 
compatible  with  Windows  NT™  was  introduced  with  Microsoft  at  Windows  World  '93  -- 
COMDEX/Spring  '93  in  Atlanta,  May  24-27, 1993, 


Dallas,  Texas,  Monday  June  7,  1993 -- The  new  desktop  video  conferencing  system  for 
PCs,  Personal  Viewpoint,  has  a  unit  selling  price  of  $1995  including  a  color  video  camera.  It 
operates  over  existing  Local  Area  and  Wide  Area  Networks  (LAN  &  WAN)  such  as  Ethernet™, 
Token-Ring™,  FDDI,  Frame  Relay,  ATM  and  other  networks.  Personal  Viewpoint  is  a 
plug-in  option  for  386, 486,  or  P5-based  IBM  PC  Compatible  Computers  with  Microsoft 
Windows  3.1.  Production  delivery  is  scheduled  to  begin  in  July,  1993. 

Personal  Viewpoint  uses  existing,  enterprise-wide.  Local  Area  and  Wide  Area  Networks, 
without  any  modifications  required,  to  provide  today's  most  cost  effective  method  for  conducting 
real-time,  full-motion  video  conferencing.  There  are  NO  telephone  company  installation  charges 
for  wide  bandwidth  telecom  lines,  NO  ongoing  monthly  connection  charges;  and  NO  time-based 
usage  charges  from  a  telecommunications  carrier. 

Glenn  Norem,  CEO  of  Viewpoint  Systems,  states  "Personal  Viewpoint  delivere  the  productivity 
of  today's  video  tefc-conferencing  room  systems  to  the  professional  desktop.  This  new  product 
empowers  the  individual  with  the  video  conferencing  technology  once  reserved  to  only  the  senior 
executives  of  the  largest  corporations." 

Operation  and  control  of  Personal  Viewpoint  is  directed  by  the  user  from  within  the  Microsoft 
Windows  environment.  Users  can  contrerf  the  size  and  location  of  the  full  motion  video  window 
along  with  other  application  information  displayed  by  the  Windows  3. 1  Graphical  User  Interface 
(GUI).  The  motion  video  is  displayed  at  30  video  frames  per  second,  and  can  be  varied  in  size  by 
the  user  from  a  full  screen  display  to  as  small  as  a  postage  stamp-size  icon.  The  user  can  choose  to 
display  the  image  being  received  cm-  the  image  being  transmitted  at  any  time  during  the  conference. 
Incoming  video  is  displayed  even  while  running  other  collaborative  Windows  applications. 


—more- 


Viewpoint  Systems,  Inc. 


press  release  (page  2) 
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DALLAS.  TEXAS  75229 
TEL  214-243-0634 
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"Personal  Viewpoint  demcmsirates  that  compressing  full-motion  video  in  real-time  and  delivering  it 
via  the  established  coiporaie-wide  networks  is  a  reality  today! "  said  Alfred  Riccomi,  member  of 
the  Moving  Pictures  Experts  Group  as  one  of  the  U.S.  Delegates  to  the  ISO  representing  the  X3L3 
standards  committee  on  MPEG. 

Personal  Viewpoint  includes  a  plug-in  ISA  bus  PC  board,  video  conferencing  softw'are,  a  color 
camera  small  enough  to  be  mounted  on  top  of  a  VGA  monitor,  cables  and  connectors,  and  TCP/IP 
software  for  $1995.  It  can  be  installed  into  any  386, 486,  or  P5-  based  PC  compatible  system 
with  a  VGA  display,  which  is  connected  to  a  Local  Area  or  Wide  Area  Netw'ork  (LAN  ifeWAN). 
The  add-in  board  accepts  video  input  from  any  standard  NTSC  video  source  such  as  a  camera, 
camcorder,  cable  TV,  VCR  or  Laser  Disc  player.  Personal  Viewpoint  is  available  without  the 
camera  for  $1595. 

MewPoint  Systems'  policy  is  to  comply  with  established  network  standards.  The  Personal 
Viewpoint  desktop  video  conferencing  system  conforms  with  the  TCP/IP  indusuy’  standard. 
Personal  Viewpoint  operates  with  network  interface  boards  that  conform  to  lE^  STD-802,3 
Ethernet  and  IEEE  STD-802,5  Token-Ring  standards.  Viewpoint  Systems  is  one  of  the  leaders  in 
an  effon  to  establish  an  industry-wide  associaaon  to  define  protocols  and  standards  for  video 
conferencing  over  packet-switched  nenv'orks  (eg.  LANs  &  WANs).  Netw'ork  gatew-ays  are 
planned  to  interconnect  Personal  Viewpoint  video  conferences  conducted  over  packet-switched 
networks  to  video  conferencing  terminals  operating  over  circuit-switched  Telecom  Networks  using 
the  CCITT  International  Standard  H.261  (^so  known  as  px64). 

The  Personal  Viewpoint  system  uses  an  innovative  packet  video  compression  technology.  It 
operates  over  existing,  packet-switched  LAN  and  WAN  networks  at  data  rates  selectable  by  the 
users  and  Network  Managers  ranging  from  64  kilobits  per  second  up  to  768  kilobits  per  second. 
The  video  frame  rate  is  selectable  by  the  user  for  a  constant  30  video  frames  per  second  or  a 
variable  frame  rate  mode  of  operation. 

Personal  Viewpoint  extends  the  video  communications  product  offerings  of  ViewPoinl 
Systems,  Inc,,  which  includes  group  conferencing  systems  that  operate  over  both  dreuit-switebed 
Tdecom  networks  and  existing  packet-switched  Local  Area  and  Wide  Area  Networks. 

Kficrosoft®  is  s  registered  trademad;  of  Kficrosoft  Corporation. 

Windows™  and  Windows  NT™  are  trademarks  of  Microsoft  Coiporatian 
Ethernet™  is  a  trademark  of  Xerox  Corporation. 

Token-Ring™  is  a  trademark  of  IBM  Corporation. 

Personal  Viewpoint™  is  a  trademark  of  VtewPoint  Systems,  Inc. 


ViewPoint  Systems  Focuses  on  IAN  Environment, 
Announces  Personal  Viewpoint  (TM)  Desktop 
Videoconferencing  System  _ 


The  Old  and  the  Nw....  the 
older  model  of  videoconferencing 
via  the  switched  telecommunica¬ 
tions  nerwork  -  and  the  new  - 
real-time  video  via  the  LAN. 
While  some  players  in  the 
videoconferencing  industr)'  have 
been  slow  to  focus  on  the  signin- 
cance  of  packet  video  over  the 
LAN,  it  is  dear  that  a  next  gen¬ 
eration  of  videoconferencing 
equipment  providers  is  emerging 
to  address  diese  issues  associated 
with  LAN  to  telecommunication 
network  connectivirj'. 

The  newly  formed  Viewpoint 
Systems,  originally  as  Bolter 
Communications,  has  been  work¬ 
ing  with  PC-based  videocon¬ 
ferencing  solutions  over  packer 
networks  with  companies  includ¬ 
ing  Sprint,  MCI,  Northern 
Telecom  and  WilTcl.  The  com¬ 
pany  is  not  new  to  the  world  of 
packet  video  and  had  developed 
the  basic  compression  technology 
10  support  videoconferencing  ca- 


Publidacd  by: 

Persona]  Technology  Reseoreh 

296  Newton  Sittct,  Suirc300 
Waltham  MA  02154 
(571)893.2600 
FAX  (617)  893-6334 


pabilifies  over  frame  relay. 
Viewpoint  Systems  has  re¬ 
cently  introduced  its  premier 
desktop  board-level  product, 
Personal  Viewpoint. 

Personal  Viewpoint  is  a  single 
ISA  386/486  PC  expansion 
board  which  enables  rcaJ-rime 
motion  video  compression  and 
decompression  via  packet 
switched  networks  using  the 
I  transport  protocol  TCP/IP 
supporting  communication 
over  LANs,  bridges  and  rout¬ 
ers,  Compressed  packer  video 
can  be  transported  across  the 
Internet,  Ethernet,  Token- 
Ring,  Frame  Relay  and  FDDI. 

The  total  price  including  the 
color  camera,  software  and 
manual  is  $1,995.  Windows 
CTM)  3.  land  a  PC  TCP/IP 
suck  are  required.  Addition¬ 
ally,  Viewpoint  Systems  will 
announce  a  version  of  the 
produa  at  Windows  World/ 
COMDEX-Spring  *93  this 
month  that  is  compatible  with 
Windows  NT,  a  Microsoft/ 


Personal  Technology  Research 


Intel  initiarive  to  link  the  PC  envi¬ 
ronment  with  the  telecommunica¬ 
tions  enviroximcnt. 

Product  Overview 
PcisonaJ  Viewpoint  uses  the 
company’s  Compressed  Packer 
Video  (CPV)  technology  support¬ 
ing  variable  bit  rate  coding  tech¬ 
niques  to  achieve  temporal  and  spa¬ 
tial  scalable  video  compression. 
Packet  networks  operate  asym¬ 
metrically,  e.g.  data  may  be  sent 
arid  received  at  different  and 
dynamically  changing  data  rates  de¬ 
pendent  on  network  traffic, 

CPV  looks  at  each  frame  of  video 
and  sends  only  those  pixels  which 
have  changed  significandy  between 
frames  and  which  are  necessary  to 
maintain  the  integrity  of  the  image. 
According  to  V’iewPoint  Systems, 
CPV  is  responsive  to  the  amount  of 
bandwidth  available  in  determining 
which  pixels  w'ill  be  transmitted 
e.g.  a  high  bandwidth  pipe  enables 
a  greater  number  of  pixels  to  be 
sent  and  therefore  fewer  artifacts. 

The  company  states  that  the  resolu¬ 
tion  of  transmitted  video  images  is 
256H  X  200V"  at  30fps.  Users  can 
select  either  me  constant  30fps 
video  frame  or  variable  frame  rate  j 
operation. 

According  to  ViewPoint  Systems, 
the  maximum  burs:  rate  is  con¬ 
figurable  from  d4kbps  to  768kbps 
and  bandwidth  parameters  can  be 
dynamically  adjusted  during  an  on¬ 
going  videoconference.  The  packet 
video  implementation  is  reported 
to  have  extremely  low  latency  at 
less  chan  70ms  and  therefore  will 
support  out-of-band  (telephone 
handset)  audio. 


Importantly,  Personal  Viewpoint  en¬ 
ables  the  user  to  work  on  an  active 
Windows  application  while  participat¬ 
ing  in  an  ongoing  videoconferenence. 
Any  Windows  application,  including 
client/server  applications  may  be  ac¬ 
cessed  during  a  videoconference. 

Other  fratures  include:  Visual  Caller 
ID,  “Key  Chat",  Video  Mute  and 
Server  Mode. 

Market  Strategy 

ViewPoin:  Systems  plans  to  market 
Personal  Viewpoint  via  established 
“LAN  100"  distribution  channels  who 
j  have  significant  experdse  in  the  sales, 
installation  and  support  of  dacacom 
ty^e  products  within  the  LAN /WAN 
enterprise  network  environment  of 
major  Fortune  2000  companies.  Ad¬ 
ditionally,  the  company  intends  to  en¬ 
courage  and  support  teaming  agree¬ 
ments  with  established  software  ven¬ 
dors  so  chat  it  will  be  posidoned  to  de¬ 
liver  applicadons  and  tools  demanded 
in  the  videoconferencing  marketplace 
for  verdcaJ  applicadons. 

Suppon  of  the  Compressed  Video 
Interoperability"  Protocol  (CVI)(1) 
Principals  of  ViewPoint  Systems  have 
publicized  die  quesdon  which  is  on 
every  ones  minds  these  days:  Now  that 
real-time  and  stored  video  transmis¬ 
sion  capabilities  have  come  to  the 
desktop  via  computer  and  communi¬ 
cations  networks,  how  do  we  create 
working  environments  which  enable 
different  platforms  and  different  ven¬ 
dors  terminal  devices  to  *^talk”  with 
one  another?  How  can  we  “grow”  the 
visual  communications  market  if  the 
industry  itself  creates  islands  of  visual 
communications  users.^ 

This  is  a  big  question  because  in  the 
world  of  video  transmission,  multiple 


coding  schemes  for  compressed 
digital  video  is  determined  by 
specific  vendor  hardware  plat¬ 
forms  and  needs.  If  governed  by 
this  paradigm,  distinct  user 
groups  have  access  to  specific  sys¬ 
tems  only,  while  to  truly  grow  the 
market  for  this  technology,  video 
communications  must  approxi¬ 
mate  a  percentage  of  the  availabil¬ 
ity  and  inter  operability’  as  is  char- 
acreristic  of  the  regular  telephone. 

Users  who  have  invested  in  a  sys¬ 
tem  which  supports  visual  tele¬ 
communications  via  PSTN  at 
Px64  should  not  have  to  abandon 
use  of  their  system  to  video¬ 
conference  with  users  of  a  packer 
video  systems  as  tiiat  offered  by 
ViewPoint.  Therefore,  the  step 
to^^’ards  the  acceptance  oFa  stan¬ 
dard  protocol  supporting  the 
interoperability'  among  as  many 
visual  cominunications  systems  is 
as  is  possible  and  appropriate,  is 
critical.  According  to  ViewPoint 
Systems,  which  is  caking  a  lead  in 
CVI  activities,  the  capability"  of 
the  CVI  Protocol  will  be  demon¬ 
strated  bcforc-thc  end  of  die  sum¬ 
mer  1993. 

(1)  Riccomi,  Alfred  and  Norem, 
Glenn,  Intcroperahilirv  for  In- 
comparible  VideQ  Codecs:  The 
**CVI"  Protocol  ,  presented  at 
MPEG  Committee  Meeting, 
March  1993. 
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InVision  Video  Teleconferencing  for  Windows 


InVision™  Video  Teleconferencing  for  Windows  is  the  result  of  an  evolutionary  approach 
developed  by  InterVision  Systems  Corporation  to  deliver  an  affordable  audio  and  ''ideo 
teleconferencing  solution  to  your  very  own  networked,  Microsoft  Windows  3.1 -based 

Unlike  other  video  teleconferencing  solutions  that  require  expensive  and  dedicated, 
single-function,  non  LAN/WAN-based  workstations,  as  well  as  costly  digital  telephone 
lines  or  satellite  links,  InVision  Video  Teleconferencing  for  Windows  uses  the  existing 
computer  network  infrastructure  to  exchange  real-time  audio  and  video  information.  Your 
existing  LANAVAN  is  no  longer  limited  to  simply  transmitting  and  receiving  data/text  files 
and  character-based  electronic  mail  messages.  InVision  gives  you  and  your  colleagues  a 
long-awaited  and  very  valuable  communications  tool  that  is  designed  to  directly  increase 
your  daily  effectiveness  and  productivity.  InVision  is  designed  for  you  and  everyone  else 
on  your  network! 


Increase  Corporate  Efficiency 

With  InVision,  corporate  network  users  now  have  a  powerful  tool  that  extends  the  power 
of  their  installed  computer  networks  beyond  file  transfers  and  exchanging  text  messages. 
Now  users  can  have  face-to-face  meetings,  across  the  corporate  campus  or  across  the 
company,  without  ever  leaving  their  office.  InVision  users  will  realize  significant  savings 
in  travel  time  and  increased  efficiency. 

The  most  effective  way  to  express  your  ideas  and  measure  their  immediate  and 
spontaneous  impact  is  through  visual  contact,  and  such  interaction  can  be  yours  with 
InVision  Video  Teleconferencing  for  Windows. 

This  is  what  you  can  expect  from  InVision  Video  Teleconferencing  for  Windows. 

•  Increased  productivity  and  efficiency 

•  Reduced  out-of-office  time 

•  Faster  and  better  decision-making  cycles 

•  More  productive  meetings 

•  Reduced  travel  time 


Compatibility  is  the  Key 

InVision  has  evolved  from  the  new  generation  of  Codec  tcompression-d^mpression)  '^, 
technology  for  the  personal  computer.  The  InVision  video  teleconferencing  solution  ‘ 
consists  of  an  Intel  i750™  based  Codec  board,  a  color  video  camera,  and  InVision 
software.  With  this  combination  of  hardware  and  software,  any  80386/486-based  PC  can 
be  upgraded  to  support  real-time  videoteleconferencing  over  any  computer  network 
platform:  Ethernet,  Token  Ring,  FDDl,  or  ISDN. 

The  InVision  communications  protocol  is  built  on  the  TCP/IP  model,  but  since  the  product 
uses  a  Virtual  Sockets  Library™  API,  it  supports  any  vendor’s  TCP/IP  stack.  Support  for 
additional  communications  protocols  is  expected  in  future  releases.  And  since  InVision 
has  been  developed  using  a  Virtual  Sockets  Library  API,  it  is  also  100-percent  compatible 
with  the  Windows  Sockets  API  standard. 


InterVision 

SVSTFMS  CORP^>RATION 


Overall  Features 

— InVision  Video  Teleconferencing  for  Windows  is  a  complete  solution  which: 

•  Allows  full-motion,  real-time  color  video  and  audio  teleconferencing. 

.  Utilizes  existing  Local  or  Wide  Area  Network  and  ISDN  infrastructures. 

•  Uses  the  international  standard  TCP/IP  as  the  transport  protocol. 

•  •  Uses  Intel  Dvr^'  and  i750-based  technology,  a  global  de  facto 

standard  for  desktop  video. 

•  Provides  phone/address  book  support. 

-  •  Operates  independently  of  other  Windows-based  applications. 

•  Uses  Microsoft's  Video  for  Windows  compatible  hardware. 

.  LAN  independent:  Ethernet.  Token  Ring,  FDDI  and  ISDN. 

•  Supports  both  NTSC  and  PAL  video  formats. 


Video  and  Connectivity  Features 

InVIsion  Video  Teleconferencing  for  Windows  offers  a  full  range  of  video 
and  connectivity  functionality: 

•  Bidirectional,  full-duplex  audio  and  video  transmission. 

•  Bandwidtn  configuration  routines  to  support  oata  transmission  rates  of 
128Kbps,  256Kbps  and  384Kbps. 

•  Adjustable  Volume.  Brightness,  Contrast,  Tint  and  Color  saturation. 

•  Uses  Host  Table  as  the  Address  Book  functions  to  maintain  names. 

•  Video  Capture  capability  to  capture  single  frames  or  sequences  of 
frames  to  disk. 

•  Capture  images  of  remote  documents  immediately. 

•  Move  and  resize  the  video  window  to  fit  your  desired  workspace  and 
screen  size. 

•  Control  your  video  with  on-screen  "mute*’  button. 

•  Review  slide  presentations  on-screen. 

•  Transfer  files,  access  remote  systems,  log-on  to  other  systems  —  all 
during  the  iive  video  teleconference  session. 

•  Operates  alongside  other  MS  Windows  applications. 

•  Windows-based  Installation. 

•  Context-sensistive  online  help. 


System  Requirements 

•  Personal  Computer  with  Intel  3860X^33  Mhz  or  higher  processor 
njnning  Microsoft  Windows  operating  system  3.1 

•  3.5"  high-densIty  (1 .44MB)  disk  drive 

•  8  MBytes  of  RAM 

•  3  MBytes  of  available  disk  space 

•  any  VGA  graphics  card  with  a  feature  connector  (or  SVGA  card  running 
in  VGA  mode) 

•  Microsoft  Mouse  or  compatible  pointing  device 

•  One  16-bit  expansion  slot 


Network  Support 

InVision  Video  Teleconferencing  for  Windows  is  fully 
compatible  with  the  following  network  adapters. 


•  3Com 

•  IBM 

•  Intel 

•  Novell 

•  SMC 

•  Any  adapter  with  ODl  or  NDIS  Drivers 

InVision  operates  over  existing  TCP/IP  based 
networks,  including: 

•  3Com  3+  Open  TCP 

•  Beame  &  Whiteside  BW-TCP  and  BW-NFS 

•  Distinct  Software  TCP/IP 

•  D-Link  TCP/IP  for  DOS 

•  Frontier  Technologies  Super-TCP/IP 

•  FTP  Software  PC^TCP 

•  HP  ARPA  Services  for  DOS 

•  Locus  TCP/IP  for  DOS 

•  Microsoft  LAN  Manager  TCP/IP 

•  NetManage  Chameleon  &  ChameleonNFS 

•  Novell  LAN  Workplace  for  DOS 

•  Spry  Air  for  Windows 

•  SunPC/'NFS 

•  Ungermann-Bass  Net'One 

•  The  Wollongong  Group  Pathway  Access  and 
Win  TCP  for  DOS 

•  Any  generic  Windows  Sockets-based  TCP/IP 


Product  Includes 

InVision  Video  Teleconferencing  for  Windows  includes: 

•  InVision  Software  -  Windows  DLL  (Dynamic  Link 
Library) 

•  Intel  i750-based  Codec  board 

•  Color  Video  Camera  and  cables 

•  External  Microphone  and  Speaker  (optional) 

•  Documentation 


Support 

InVision  Video  Teleconferencing  for  Windows  comes 
with  90  days  of  telephone  technical  support.  Annual 
software  maintenance  support  is  available  as  an 
option. 


Call  for  free  interactive  multimedia  brochure  for  InVision. 

InVision  is  fully  compatible  with  Microsoft®  Windows^*^,  Intel®,  DVI®  multimedia, 
lndeo^“  Video  technology,  and  iyso^"! 

InterVision  Systems  Corporation 

2232  Richelieu  Drive,  Suite  100  •  Vienna,  Virginia  221 82  •  CompuServe:  72002,1677 
Telephone:  (703)  560-1446  •  Fax:(703)560-4364  •  Internet:  wk05020(S>worldlink.com 

I  INI  T  E  R\/ I  S I  O N  InVision  and  InterVision  are  trademarks  of  InterVision  Systems  Corporation. 

S'.  si  I  Ms  c  .<  >u(><  ,i<M  II  )N  Ail  other  products  are  trademarks  ol  their  respective  manufacturers. 
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SOURCE:  Stephen  Hall,  Monash  University  (Australian  IJVC  Consortium) 

TITLE:  Paekedsation  of  H.22 1  frames  for  LANs 

PURPOSE:  Discussion 

Abstract 

A  means  of  adaptin^i  HJ20  terminals  for  use  on  packet  switched  LANs,  in  which  the  H 221  frame  structure 
is  retained,  w  discussed.  The  appeal  of  this  approach  is  that  it  alh/ws  maximum  use  to  be  made  of  existing 
H  J20^related  recvfmnendations  and  eguip?nent.  H<rwcver,  the  effect  of  packet  loss  is  identified  as  an 
important  unresolved  issue,  requiring  further  study. 

1 .  Introduction 

The  adaptation  ol  H.32()  audiovisual  terminals  to  packet  switched  LANs  has  been  considered  in  A  VC-5 12 
and  AVC-513.  In  AVC-512,  it  was  concluded  that  the  replacement  of  the  H.22I  multiplex  and  framing 
structure  with  an  alternative,  H.22z,  would  pmvide  the  greatest  benellts  in  terms  of  performance  and 
Hexibility.  Nevertheless,  it  was  reec^gnised  that  the  design  of  \{22z  was  a  substantial  task,  and  that  this 
approach  might  preclude  the  use  of  existing  HJi2()  hardware  in  H32z  terminals.  The  alternative  H.22 1- 
based  appmach  is  therefore  discussed  further  in  the  present  document,  in  order  to  provide  greater  insight  into 
the  relative  merits  of  the  two  appn>aches. 

2.  Network  configuralion 

An  (*XHrnpl{’  network  iv  ^ihdwn  in  Fig  I  In  this  vr(TiHnn.  im  H  n?/  frrmin;d  rrmneefed  tn  « 

LA.\  is  able  to  communicate  with  another  H.32z  terminal  on  the  same  LAN,  as  well  as  with  a  remote 
H.32()  terminal  connected  to  an  LSDN  netw(5rk.  In terw' (irking  with  an  H.32x  terminal  connected  h)  a  B- 
ISDN  network  is  also  possible,  assuming  that  the  H.32x  terminal  has  an  H.32()  compatibility  mode. 


[  Public 

Customer  premises  network  .  network 


Fig.  I  An  example  netNvork  configuration 

The  function  o!'  the  gateway  is  to  terminate  the  packet  pnjtoeols  used  on  the  LAN.  However,  it  d(x:s  not 
need  to  perform  any  special  operatitms  on  the  H.22 1  bit  stream  itself  (such  as  remultiplexing),  so  its 
pmeessing  load  is  relatively  low.  It  is  therefore  likely  that  existing  LA.\  data  gateways  could  be  adapted  for 
this  application  by  means  ol' a  software  upgrade. 

2.  Frolocol  slack 

A  possible  protocol  stack  in  an  H.32z  tenninal  is  shown  in  Fig.  2.  At  the  lowest  layer,  the  LAN  protocol 
C(mtrols  access  to  the  physical  medium,  andpn)vides  basic  functions  such  as  framing  and  bit  error  detection. 
Abt^ve  this,  a  "packet  adaptation  layer”  implements  the  additional  functions  requinjd  to  handle  real-time 
trulllc,  .such  ua  timing  recovery.  It  thus  appears  to  a  device  above  the  adaptation  layer  (in  particular  an 
H.32()  terminal),  that  it  is  talking  directly  to  an  ISD.N  terminal  adapter. 
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Fig.  2  Possible  pn>tocol  stuck  in  un  H.32z  termina] 

In  addition  to  the  H.22I  bitstream,  it  is  necessary  to  provide  a  path  for  the  end-to-netwoik  signalling  (in 
particular,  call  control  signalling)  Irom  the  HJ52z  terminal,  acr()ss  the  LAN,  to  the  ISDN  network.  This 
can  be  done  by  encapsulating  ISDN  D-channel  messages  within  LAN  packets. 


3  .  Packet  adaptation  layer  design  issues 

Data  Alignment 

An  H..'^2()  terminal  transmits  and  receives  streams  of  data  at  a  constant  bit  rate.  The  simplest  way  of 
cann  ing  this  information  across  a  packet  switched  LA.N  is  to  segment  a  bit  stream  into  blocks  of  a  suitable 
size  (say  a  few  hundred  bytes),  and  then  to  put  these  blocks  into  packets.  It  may  at  first  appear  that  the 
packetisation  process  should  be  aligned  to  the  H.22I  framing  structure,  so  that  a  packet  always  contains  an 
integral  number  oi' frames.  This  technique  can  impnwe  loss  resilience  when  applied  to  the  packetisation  of 
individual  media  streams  (eg.  aligning  packets  to  video  GOBs,  as  described  in  AVC-.5 13).  However,  in  the 
configuration  described  here,  the  media  streams  have  already  been  multiplexed  into  H.22I  frames  in  such  a 
wav  that  there  is  no  alignment  t(^  media  units.  Furthermore,  the  fact  that  the  H.22I  frames  are  of  a 
constant  length  makes  it  relatively  straightiorv^ard  for  the  packet  adaptation  layer  to  maintain  the  H.22I 

ftaiitv.  ckltLJcLuiu  ill  Oiu  il  hi/w  iiiucli  daUi  ]ia3 

reasons.  packeL'frame  alignment  is  not  necessary  ,  which  gives  greater  i'Tcedom  in  the  choice  of  the  packet 
size. 

Packet  size 

The  packet  size  on  popular  LA.Vs  (eg.  Ethernet,  Token  Ring,  FDDI)  can  be  chosen  by  an  application  from 
a  fairly  wide  range,  typically  64  -  1.500  bytes,  with  a  packet  header  of  20  -  30  bytes.  TTie  need  to  minimise 
the  packetisation  delay  at  low  bit  rates  leads  to  the  requirement  for  fairly  short  packets,  in  the  region  of  a 
few  hundred  bytes.  For  example,  when  the  H.22I  bit  rate  is  128  kbit/'s,  a  packet  payload  of  320  bytes 
takes  20  ms  to  accumulate.  The  packetisation  delay  is  incurred  at  each  point  where  data  enters  the  LAN,  ie. 
once  in  the  transmit  direction  and  once  in  the  receive  directitm  in  Fig.  1 . 

In  general,  successive  LA.V  pac’kets  may  have  different  sizes.  However,  in  this  application,  a  fixed  packet 
size  is  appnipriate,  as  this  corresponds  to  a  constant  packetisation  delay,  and  makes  it  easier  to  decide  ht)w 
much  dummy  data  should  be  generated  to  replace  a  lost  packet. 


Packet  loss 

LA.V  pnitocols  automatically  perform  error  checking  on  both  header  and  payload  bits,  and  corrupted  packets 
are  discarded.  However,  LANs  typically  have  very  low  bit  error  rates,  in  the  region  of  Kf^,  so  that  packet 
losses  due  to  bit  errors  are  correspondingly  rare.  Packet  losses  due  ti^  queue  overflows  are  more  likely ,  but 
can  be  minimised  by  good  network  design  and  management.  In  any  event,  the  loss  of  a  packet  containing 
H.22i  data  is  equivalent  to  a  length)  error  burst  on  un  LSD.V  ehunnel  (assuming  that  the  lost  packet  is 


;r^ 


Tvpluccd  with  dummy  duta).  This  may  have  a  severe  subjective  elTeet  on  the  eommunicatiem,  particularly  if 
it  causes  a  l(5ss  of  H.22 1  frame  or  multilrame  alignment  in  the  H.32()  terminal.  It  is  to  be  expected  that  the 

j^acXvL  liavu  a  ciiiiOcLu/it  wiJi  Uiu  uITwcL  iil*  j^oeXeC  Uia»,  UuL  tu^  v|uaiiLit4xU  vc  ivaulld  (Jua 

issue  are  available  at  present. 

Packet  loss  can  be  detected  in  the  LAN  envinmment  by  means  of  sequence  numbers  in  the  packet  headers. 
It  may  therelbre  appear  that  the  effect  of  packet  loss  on  the  video  signal  could  be  mitigated  by  initiating  a 
picture  relresh  through  a  "Fast  Update  Request'*.  However,  this  BAS  code  can  only  be  sent  in  the  H.22 1 
service  channel,  which  is  not  available  U)  the  packet  adaptation  layer. 

In  contrast,  the  loss  (5f  a  LAN  packet  containing  end-to-network  signalling  will  be  taken  care  of  by  the  D- 
channel  pnjtocol,  which  will  automatically  perform  retransmission. 

Timing  recovery 

As  the  transport  time  m  packet  switched  LANs  is  variable,  it  is  necessary  to  buffer  the  received  packets  in 
the  adaptation' pn:toco1,  in  order  to  recreate  a  constant  bit  rate  stream.  The  extra  delay  incurred  in  this 
process  can  be  kept  small  by  minimising  the  packet  jitter  thn)ugh  appropriate  design  and  contnil  of  the 
LAN. 

The  fact  that  the  ISDN  network  clock  is  not  directly  available  to  the  H..32z  terminal  must  also  be  taken 
intc2  account.  This  means  that  the  H.32z  terminal  may  produce  data  faster  than  it  can  be  transmitted  on  the 
ISD.N  link,  leading  to  data  loss.  A  solution  is  to  generate  a  suitable  clock  signal  within  the  packet 
adaptation  layer,  and  to  lock  this  to  the  ISD.N  network  clock,  by  passing  How  control  inlbrmation  acmss 
the  LA.N  in  the  packet  headers. 

4.  (3onclu>sion 

One  appn)ach  to  creating  an  H.32z  terminal,  in  which  the  H.22 1  bitstream  and  signalling  messages  fnm  a 
conventional  H.32()  terminal  are  packetised,  has  been  discussed.  The  advantages  are  that  maximum  use  is 
made  of  existing  H.32()-related  recommendations  in  the  H.32z  design,  and  that  existing  H.32{)  equipment 
may  be  converted  to  H.32z  by  means  of  an  "add-on"  adapter.  However,  the  subjective  impact  of  packet  loss 
is  unkniium,  and  I’urthcr  .study  of  this  issue  is  therelbre  required  beibre  a  conclusitm  can  be  reached  on  the 
leasibility  ol' this  appniach. 
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TITLE:  H.22z  protocol  for  LANs 

PURPOSE:  Proposal 

Abstract 

This  document  describes  an  H.22z  protocol  for  transporting  real-time  audiovisual/multimedia 
information  over  packet  switched  local  area  computer  networks.  The  required  functions  are 
kientified,  and  a  corresponding  packet  structure  is  proposed. 

L  Introduction 


Document  AVC-513 
July  1993 


Document  AVC-512  discusses  the  basic  design  of  an  H.32z  terminal,  which  is  intended  for  connection  to 
packet  switched  local  area  networks  (LANs).  The  present  document  describes  an  associated  H.22z  protocol, 
which  provides  the  terminal  with  a  means  of  conveying  multimedia  information  across  the  LAN.  The 
H.22z  protocol  assumes  that  the  LAN  is  able  to  transport  packets  between  two  or  more  network  nodes 
within  suitable  delay  bounds,  but  with  no  guarantee  of  delivery  (ie.  using  an  "unacknowledged  datagram" 
service).  Such  a  service  can  be  offered  on  suitably  configured  Ethernet,  Token  Ring,  FDDI  and  ATM 
LANs,  which  incorporate  basic  resource  allocation  mechanisms  in  network  switches  and  routers.  Examples 
of  unacknowledged  datagram  protocols  include  IEEE  802.2  LLC  Type  1,  and  Internet  IP.  The  H.22z 
protocol  adds  functions  to  enhance  the  basic  datagram  service  as  appropriate.  For  example,  it  implements 
an  automatic  retransmission  scheme  to  correct  errors  in  end-to-network  signalling  streams.  A  layered 
protocol  model  incorporating  is  £hown  in  Fig.  1. 
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Fig.  1  Layered  protocol  model  incorporating  H.22z 


2.  Functions  of  H.22z 

•  Packctisaiion:  The  H.22z  protocol  must  segment  the  various  data  streams  into  units  which  arc  suitably 
sized  for  transport  on  the  LAN.  The  length  of  each  LAN  packet  can  be  matched  to  the  bit  rate  of  the 
associated  data  stream,  in  OTder  to  minimise  the  packetisation  delay.  Where  a  natural  data  unit,  or 
"message",  is  present  in  the  stream,  such  as  a  video  GOB  or  slice,  then  it  may  be  advantageous  to  align 
the  packets  with  these  data  units.  For  example,  the  effects  of  packet  loss  on  video  quality  can  be- 
reduced  by  aligning  GOBs/sIices  to  packets.  However,  since  a  long  message  may  span  more  than  one 
packet,  an  indication  of  the  last  packet  in  the  message  is  required,  in  order  to  minimise  the  reassembly 
delay.  This  can  be  provided  by  a  "segment  type"  field  in  the  H.22z  packet  header,  which  indicates  that 


the  packet  contains  the  beginning  of  a  message  (BOM),  the  continuation  of  a  message  (COM),  the  end 
of  a  message  (EOM),  or  a  single  segment  message  (SSM).  In  addition,  it  is  possible  that  mesMges  will 
not  be  aligned  to  byte  boundaries  in  the  packet  payload.  An  example  is  where  the  payload  is  created 
by  segmenting  a  continuous  bit  stream  from  a  video  codec.  The  provision  of  pointers  in  the  H.22z 
packet  header  to  the  first  and  last  bits  in  the  payload  avoids  the  need  for  time-consuming  bit-shifting 
operations  prior  to  packeiisation. 

•  MulUplcxliig:  As  UcscrlbcU  In  Uucuiticni  AVC-312,  tlic  H.ZZc  piuiLvul  i»  icquiicO  mj  piuviUc  « 

multiplexing  function  for  the  various  data  streams  from  a  single  terminal.  Furthermore,  a  packet 
multiplex  approach,  where  each  packet  contains  only  one  type  of  data,  is  shown  in  AVC-512  to  be 
preferable  to  one  based  on  the  encapsulation  of  H.221  frames.  This  leads  to  the  requirement  for  a 
"stream  identification"  field  in  the  H.22z  packet  header.  The  field  should  be  sufficiently  large  to  allow 
the  identification  of  su'eams  from  multiple  terminals,  in  order  to  accommodate  future  multipoint 
configurations. 

•  Error  handling:  Packets  may  be  lost  on  LANs  due  to  bit  errors  or  queue  overflows.  Bit  error  rates  on 
LANs  are  very  low,  typically  10'^,  and  queue  overflows  can  be  avoided  through  proper  network  design 
and  management.  Neverthele.s.s.  the  ln.s.ses  which  do  occur  mu.st  be  detected  by  the  H.22z  protocol,  and 
this  can  be  done  using  a  sequence  number  in  the  H.22z  packet  header.  In  addition,  appropriate  action 
must  be  taken  once  an  error  has  been  detected.  In  the  case  of  lost  audio  or  video  information,  the 
terminal  must  be  informed  of  the  occurrence  and  location  of  the  loss,  in  order  to  allow  it  to  employ  its 
own  error  concealment  or  recovery  techniques  (eg,  a  "fast  update  request").  In  contrast,  lost  end-to- 
network  signalling  information  can  simply  be  retransmitted.  However,  special  measures  must  be  taken 
to  avoid  the  loss  of  end-to-end  signalling  and  C&I  information  (eg.  BAS),  since  this  may  be  delay- 
sensitive.  For  example,  packets  containing  such  information  can  be  duplicated  prior  to  transmission. 

•  Timing  recovery:  Most  LANs  operate  asynchronously,  implying  that  there  is  no  fixed  timing 
relationship  between  successively  delivered  packets.  Furthermore,  there  is  often  no  master  network 
clock  which  can  be  used  as  a  timing  reference  by  the  terminals.  The  H.22z  protocol  must  theretore 
provide  a  means  of  recovering  the  timing  between  packets,  and  synchronising  the  terminals.  This  can 
be  done  using  a  combination  of  buffering  and  sliding  window  flow  control,  leading  to  the  requirement 
for  a  numbered  acknowledgement  field  in  the  H.22z  packet  header. 

3.  Packet  structure 

A  structure  for  H.22z  packets,  designed  according  to  the  above  requirements,  is  shown  in  Fig.  2.  Note  that 

the  H.22z  packet  header  is  only  3  bytes  long,  while  the  payload  may  be  several  hundred  bytes  in  length,  so 

that  the  packet!  sation  overhead  is  very  low. 


SiD 

SEQ 

ACK 

ST 

PF 

PL 

PAYLOAD 

SID  e  Stream  identifier  (8  bits) 

SEQ  =  Segment  sequence  no.  (4  bits) 

ACK  ■  Acknowledgement  no.  (4  bits) 

ST  =  segment  type  ■  bom,  com,  eom  or  ssm  (2  oits) 
PF  c  Pointer  to  first  bit  in  payload  (3  bits) 

PL  =  Pointer  to  last  bit  in  payload  (3  bits) 

Fig.  2  H.22z  packet  smjcture 


4.  Conclusion 

A  simple  protocol  for  transporting  multimedia  information  from  H.32z  terminals  across  packet  switched 
LANs  has  been  proposed.  Further  work  is  required  to  specify  its  operation  in  detail. 
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TITLE;  Design  of  H.32z  terminals  for  LANs 

PURPOSE:  Proposal 

Abstract 

The  demand  for  access  to  multimedia  services  from  LAN-attached  desktop  computers  is 
increasing,  and  a  standards-based  solution  will  ensure  maximum  connectivity  is  achieved, 
through  interworking  with  existing  and  future  TSS  SG15  terminals.  Two  options  for  the  design  of 

H. 32Z  terminals  are  proposed,  and  it  is  concluded  that  the  scheme  in  which  the  various  data 
streams  are  multiplexed  into  separate  LAN  packets  offers  the  greatest  benefits. 

I.  Introduction 

There  is  a  growing  demand  from  users  for  access  to  audiovisual/multimedia  services,  using  desktop 
computers  which  are  attached  to  packet  switched  local_area_jieiwDiks_/LANs).  While.  pronrifttarv_ 
solutions  suitable  for  local  or  closed-user-group  communications  are  emerging,  wide  connectivity  can 
only  be  achieved  through  a  standards-based  approach,  In  particular,  interworking  with  terminals  covered 
by  current  and  future  TSS  SG15  recommendations  (eg.  H.320  and  H.32x)  is  required.  With  this  in  mind, 
and  considering  the  many  similarities  between  packet  switched  LANs  and  ATM  networks,  we  believe 
that  the  Experts  Group  is  in  the  best  position  to  develop  the  appropriate  recommendations  (H.32z,  H.22z, 
etc.). 

Existing  and  future  packet  switched  LANs  arc  likely  to  incorporate  a  range  of  networking  technologies, 
including  Ethernet,  Token  Ring,  FDDl  and  ATM.  The  common  denominator  in  such  LANs  is  the  ability 
to  transpon  variable-length  packets  asynchronously  between  network  nodes  (involving  segmentation  and 

reassembly  In  Uic  case  uf  ATM).  By  llic  network  appropriately,  and  using  bandwidth 

allocation  mechanisms  in  network  routers  and  switches,  the  delay  constraints  imposed  by  real-time 
multimedia  traffic  can  be  satisfied. 

An  example  network  configuration  is  shown  in  Fig.  1,  where  two  H.32z  terminals  are  connected  to  a 
high-speed  LAN  backbone  via  dedicated  Ethernet  and  Token  Ring  segments.  The  LAN  hub  allocates 
bandwidth  for  the  real-time  traffic  and  switches  packets  between  the  different  LAN  segments.  A  gateway 
between  the  LAN  and  the  public  network  allows  communication  with  remote  H.320  and  H.32x  terminals, 
by  converting  between  the  H.22z  protocol  used  on  the  LAN  and  the  H.221  or  H.22x  protocols  used  in  the 
public  network.  Note  that  the  gateway  is  part  of  the  customer  premises  network,  but  it  has  standard 
ISON  and  B-ISDN  network  interfaces. 
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Fig.l  Example  network  configuration. 


2. 


HJ2z  Terminal  Design 


We  consider  below  two  ways  of  creating  an  H.32z  terminal,  by  convening  an  H.320  terminal  for 
operation  on  a  packet  switched  LAN.  Essentially,  these  involve  making  a  "cut"  through  the  existing 
design  in  one  of  two  places  (marked  A  and  B  in  Fig.  2),  and  implementing  a  new  H.22z  irotocol  for 
transporting  the  multimedia  information  across  the  L^.  This  approach  makes  substantial  use  of 

modulec  covered  by  exieting  recommendationc,  and  should  therefore  enable  the  realisation  of  H.322 

terminals  in  the  near  future. 


B  A 


B  A 

Fig.  2.  H.320  terminal  structure  [from  TSS  Rec.  H.320,  Figure  1/H.320, 1990] 


Scheme  A; 

In  this  approach,  the  H.221  framing  function  is  retained  in  the  H.322  terminal,  and  one  or  more  H.221 
frames  are  placed  into  packets  for  transmission  across  the  LAN.  The  benefits  of  this  approach  are; 

•  There  is  minimal  disruption  to  the  existing  H.320  terminal  design. 

•  The  temporal  relationship  between  the  various  data  streams  established  by  the  H.221  frame  is 
implicitly  maintained  across  the  LAN. 

Scheme  B; 

In  this  approach,  the  multiplexing,  framing  and  network  interface  functions  which  are  ^leciflc  to  ISDN 
(or  B'ISDN)  are  omitted  from  the  H.32z  terminal,  and  placed  in  the  gateway.  Each  data  stream  (video, 
audio,  signaling,  etc.),  is  then  transmitted  separately  across  the  LAN,  ie.  using  a  different  LAN  packet 
for  each  type  of  data.  Scheme  B  offers  the  following  benefits: 

•  Different  data  streams  can  be  provided  with  the  appropriate  quality  of  service  on  the  LAN.  For 
example,  automatic  retransmission  can  be  provided  for  corrupted  or  lost  end-to>network  signalling 
information,  whereas  the  extra  delay  incurred  makes  this  inappropriate  for  audio  and  video. 

•  There  is  scope  for  implementing  advanced  service  features  by  making  use  of  the  unique 
characteristics  of  the  LAN  environment.  For  example,  multicast  packet  addresses  can  be  used  to 
send  video  and  audio  information  simultaneously  to  a  number  of  terminals  on  the  LAN.  Similarly, 
an  audio  stream  can  be  separately  routed  to  a  terminal  which  does  not  have  a  video  capability. 


•  Any  increase  due  lo  packetisation  in  the  end*to-end  audio/video  delay  cah  be  minimised,  by  varying 
the  LAN  packet  length  according  to  the  occupancy  of  the  video  coder  output  buffer.  In  this  case  the 
buffer  will  be  emptied  in  bursts,  so  that  it  will  be  necessary  to  perform  the  video  rate  control  function 
using  a  "virtual"  buffer  (ie.  an  up/down  counter),  rather  ttan  the  physical  buffer. 

•  The  H.322  terminal  is  more  amenable  to  incorporation  in  desktop  computers,  since  the  H.221  bit- 
oriented  multiplex  is  replaced  by  a  byte-oriented  approach.  This  facilitates  access  by  aRJIication 
software  to  signalling  arid  user  data  in  the  multimedia  streams. 

•  Extension  to  higher  bit  rates  is  facilitated.  For  example,  it  may  be  desirable  in  the  future  to  create  an 
H.32Z  terminal  which  can  handle  a  bidirectional  video  stream  at  CIF  resolution  for  conversational 
services,  and  a  unidirectional  stream  at  a  higher  ^atial  resolution,  for  retrieval  services.  The  flexible 
nature  of  packet-oriented  multiplexing  allows  such  enhancements  to  be  added  without  redesigning 
the  multiplex. 

3.  Conclusion 

Two  ways  of  designing  an  H.32z  terminal  for  use  on  packet  switched  LANs  have  been  de^bed.  On 

balance,  the  benefitc  offered  by  ccheme  B,  in  which  the  individual  data  etreamc  are.  mnltijvleTed  into 

separate  LAN  packets,  are  considered  to  outweigh  those  offered  by  scheme  A,  which  is  based  on  the 

encapsulation  of  H.221  frames.  An  H.22z  protocol  designed  according  to  scheme  B  is  proposed  in  AVC- 

513.  Further  work  is  required  to  establish  whether  other  portions  of  the  H.320  terminal  (eg.  H.242, 

H.230)  need  to  be  modified  for  the  LAN  environment.  In  addition,  the  potential  for  harmonisation  of 

R32z  with  H.32x  and  associated  recommendations  should  be  considered. 
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Title  :  Video  and  Audio  Communication  System  for  CSMA/CD  LAN 

Purpose ;  Information 

1.  Introduction 

NTT  has  developed  a  realtime  video  and  audio  communications  system  for  10  Mbps 
CSMA/CD  LAN.  This  system  consists  of  an  audio-video  realtime  communication  adapter  and  ISDN 
visual  telephone  gateway.  This  adapter  establishes  connection  by  TCP  protocol,  and  transmits  audio 
and  video  data  with  18-208  kbps  by  UDP.  ITU-T  Rec.  H,28l  and  G.728  coding  algprithms  are  used 
for  coding/decoding  video  and  audio  respectively.  For  real-time  audio-video  communication  over 
LANs,  congestion  control  and  video  frame  refresh  controls  are  implemented.  The  .ISDN  visual 
telephone  gateway  realizes  interconnection  between  the  audio-video  real-time  conwunication 
adapter  and  ISON  visual  telephone  terminal  based  on  (TU-T  rec,  H.320  terminal. 

2.  Service  concepts 

Fig.1  shows  the  audio-video  tele-conference  system.  PCs,  WSs  and  the  audicwideo  real¬ 
time  communication  adapters  are  connected  with  10  Mbps  CSMA/CD  LANs,  LAN-to-LAN 
connections  can  be  made  via  basic-  or  primary-rate  ISDN  circuits.  ISDN  visual  telephone  gateway  is 
for  Interconnection  between  the  adapter  and  ISDN  visual-telephone  based  on  ITU-T  H-series 
Recommendations. 

(1)  Audio-Video  real-time  communication  over  LANs  and  WANs 

The  adapter  can  establish  a  connection  wrtii  another  adapter  over  LANs  or  WANs. 
Transmission  rates  of  audio  and  video  are  16  kbps,  and  16-192  kbps  variable,  rtspectively.  The 
maximum  transmission  rate  of  the  pair  is  208  kbps.  When  5  pairs  of  ada^ers  with  208  kbps 
transmisaon  rate  are  communicated  at  the  same  time,  h  occupies  about  2.1  Mbps  of  10  Mbps 
CSMA/CD  LAN  capacity.  If  these  terminals  are  set  at  144  kbps  ( 128  kbps  for  wdoo  and  16  ki^  for 
audio ),  total  bltrate  of  audio-video  communication  Is  about  1.4  Mbps. 

<2)  Interconnection  between  audio-video  real-time  communication  adapter  and  ISDN  visual  telephone 
The  ISDN  visual  telephone  gateway  resdizes  Interconnection  between  the  audio-video 
realtime  communication  adapter  and  ISDN  visual  telephone  based  on  ITU-T  Recommendations.  The 
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gateway  converts  communication  protocol  and  video-audio  data  frame  format  only,  tye^a^****  these 
both  equipments  Implement  fTU-T  Rec.  video  coding  scheme  and  Q.728  audio  ooding  acheme. 
However  when  an  ISDN  visual  telephone  has  only  G.711  audio  coding  scheme,  the  gateway 
transcodes  these  coding  schemes  mutually. 

3.  Communication  protocols  and  congestion  control 
3.1  Communication  protocols 

Figure  8  shows  a  call  setup  and  release  sequence  over  LAN.  TCP  protocol  Is  used  for  these 
connection  establishment  sequence,  and  UDP  datagram  transmission  Is  used  for  realtime 
transmission  of  coded  audio  and  video  data. 

(1)  Call  setup 

The  adapter  Initiates  a  call  when  the  adapter  gets  'call'  command  with  IP  address  parameter 
from  PC/WS.  The  adapter  transmits  call  setup  commands  to  a  destination  adapter  In  TCP.  The 
desSnation  adapter  responds  with  call  setup  accept  command  when  the  adapter  establishes  the  call. 
These  commands,  call  setup  and  call  setup  accept,  have  some  parameters  which  Indicate  audio  data 
length,  video  encoder  transmission  capability,  video  decoder  mode  request,  etc. 

(2)  Coded  audio  and  video  data  transmission 

The  adapters  send  and  receive  audio/video  coded  data  with  UDP.  The  audio  data  and  video 
data  are  combined  in  a  packet  to  decrease  the  number  of  packets,  and  transmitted  et  regular  intervals. 
This  is  to  achieve  better  transmission  efficiency.  The  packet  structure  is  shown  in  Rgure  4.  A  packet 
consists  of  a  control  command,  a  sequence  number,  an  audio  data  length,  a  video  data  length, 
coded  audio  data  and  coded  video  data.  The  control  command  indicates  fast  update  request,  loop 
back  request  and,  transmission  and  reception  bit  rates.  The  sequence  number  shows  the  packet 
number  and  is  used  for  detecting  packet  low  by  checking  H  continuity,  the  audio  data  is  fixed  at  0, 
70, 110  or  150  bytes  in  a  packet  The  video  date  is  filled  with  variable  length  coded  data  at  regular 
Intervals  In  a  packet 

(3)  Call  release 

The  adapter  releases  a  call  when  the  adapter  gets  ‘release’  command  from  PC/WS.  The 
adapter  transmits  release  command  to  the  destination  adapter  by  TCP,  then  stops  audKMrIdeo  data 
transmission  through  UDP  data  packets. 

3.2  Congestion  control 

The  UDP  is  very  simple  and  easy  to  process,  so  it  can  suit  realtime  data  transmission. 
However,  when  LAN  traffic  becomes  heavy,  UDP  packets  are  diecarded.  The  adapter  can  detect  a 
packet  discard  checking  the  sequence  number  in  the  data  packet,  then  lowers  video  throughput  by 
one  step  automatically  to  relieve  congestion  and  sets  the  encoder  in  fast  update  mode  to  dear 
decoded  video.  When  congestion  persists,  H  adjusts  rate  one  step  further.  Transmission  rates  return 
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to  their  onginal  speed  once  conpestion  is  cleared.  If  some  audio  data  is  lost.  It  is  replaced  with  silence 
data  to  maintain  audio-video  synchronization. 


InteroonnecUon  with  ISDN  visual  telephone 

Figure  4  shows  an  intenoonnection  aefluence  between  LAN  terminals  end  ISDN  equipments. 

(1)  Call  setup 

Video  and  audio  transmission  modes  of  both  LAN  and  ISDN  temtinals  are  set  In  this  step. 

(2)  Audio^vldeo  communication 

The  gateway  converts  data  frame  format  and  audio  coding  schemes.  The  video  codec  of 

^  .  but  has  no  BCH  forward  error  code  scheme.  The  gateway 

a  ds  forward  error  codes.  Since  the  audio  codec  of  the  adapter  has  only  Q.728.  the  gateway 
ir^scodes  it  to  G.71 1  coding  scheme  if  G.728  is  not  supported  by  the  ISDN  terminal.  When  a  visual 
le^hone  has  Q.728.  the  gateway  simply  transfers  the  audio  data.  Then  the  gateway  multiplexes 
coded  audio  and  video  data  in  H.221  frame  for  an  ISDN  visual  telephone. 

To  avoid  overflow  of  coded  video  data  from  the  adapter  to  the  ISDN  terminal,  the  gateway’ 
sets  video  data  transmission  rate  of  the  UN  terminal  lower  than  the  one  for  UN-to-LAN 
^muncation.  For  example,  if  2B  is  the  ISDN  rate  with  Q.728.  LAN  video  rate  Is  set  to  77  kbps. 
When  video  buffer  is  in  under  flow,  fill  bits  are  buried  in  BCH  frames. 

4.  Design  concept  and  terminals 

Hardware  architecture  of  audio-vddeo  real-time  communication  adapter  and  ISDN  visual 
telephone  gateway  are  described  here. 


4.1  AudIo*vtdeo  real-tline  communication  adapter 

oiv. , .  ^  ®  LAN  IF  has  10  Mbps  CSMA/CD  LAN  ( ISO 

«»-3 10BASE5 )  interface,  treats  TCP/IP  prctoooi.  and  communicates  control  data  In  TCP  and  coded 
au  o-video  data  m  UDP.  PAD  packs  coded  audio  and  video  data  in  a  packet.  VIDEO  CODEC 
^es  and  decodes  video  signals  based  on  mj-T  Rec.  H.281.  However,  the  video  codec  has  no 
correction  framing  pattern.  This  is  because  the  UDP  packet  has  checksum  and 

detects  Wt  error, 

Fwn.  rate  is  IS  i/s  h  OF  «.d  30  i/s  in  QOIF.  Dsts  tale  1. 183  kbps  B  maximum.  AUDIO  CdDEC 

es  and  decodes  audio  slgnel  based  according  to  ITU-T  Rac.  6.728.  Oats  rate  is  IS  kbps  fixed. 

Audlon/ldeo  resl-time  communicadon  adapter  Is  shown  in  Rgure  8,  and  the  specitioations 
ere  summerized  in  table  1. 
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45  ISDN  video*phon6  oateway 

Figure  7  shows  a  block  diagram  of  the  gateway.  LAN  IF  has  10  Mbps  CSMA/CD  LAN  ( ISO 
802-3 10BASE5 )  Interface,  and  eommunloates  tidth  an  audio^deo  real-time  oommunloaUon  adapter.' 
PAD.  packa/aepamtes  coded  audio  and  video  data  &\/from  a  packet  ACX5  transcodee  au(So  data  when 
6  visual  telephone  has  only  6.71 1  audio  oodec.  When  a  ^aual  telephone  has  Q.728  audio  code^  Ihe 
ACC  transfers  It  The  video  oodec  of  the  adapter  has  no  BCH  forward  error  code  scheme,  EOF  codes 
and  decodes  BCH.  MUX  multiplexes/demultiplexes  coded  audio  and  video  data  In/from  frame. 
NIF  has  an  interface  of  basic-rate  ISDN  droults.  and  communicates  an  ISDN  visual  telephone. 

Table  2  summarizes  the  specifications  of  the  gateway. 

5.  Conclusion 

Information  on  an  Implementation  of  video  and  audio  communication  system  for  LAN  has 
been  provided  to  feciiitate  making  a  standardization  program. 
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Program  for  the  introduction  of  FPLMTS 


1.  Purpose 

The  FPLMTS  Program  identifies  short  and  long  term  milestones,  in 
the  form  of  specific  output  documents,  the  time  scale  for  their 
production  and  the  allocation  of  responsibilities. 

2.  High  level  program 

A  diagrammatic  representation  of  the  conceptual  high  level  pogram 
is  contained  in  Figure  1  with  a  detailed  description  of  each 
element  provided  in  Table  1. 

It  should  be  noted  that  the  concepts  may  need  to  be  applied 
differently  on  a  per  issue  basis,  for  example,  in  some  cases, 
particular* elements  may  not  be  applicable  and  hence  may  be 
bypassed. 

3.  Milestones  for  the  overall  definition  of  FPLMTS 

The  milestones  for  the  overall  definition  of  FPLMTS  have  been  given 
in  annex  1.  These  milestones  are  identified  from  a  top-down 
perspective  with  the  view  to  get  FPLMTS  in  operation  around  the 
year* 2000.  The  milestones  are  given  irrespective  of 
responsibilities  within  the  ITU. 

4.  Framework  of  detailed  recommendations  for  FPLMTS 

The  framework  of  detailed  recommendations  for  FPLMTS  is  given  in 
annex  2.  The  detailed  recommendations  are  the  complete  and 
detailed  description  of  all  aspects  of  FPLMTS  t.hat  are  necessary  to 
qet  FPLMTS  in  operation.  Baseline  recommendations  needed  in  ^e 
interim  to  arrive  at  specific  decisions  are  not  included  in  this 

framework. 

It  should  be  noted  that  the  framework  of  detailed  recommendations 
in  annex  2  does  not  identify  explicit  CCIR  or  CCITT_ 
recommendations,  but  is  more  to  be  seen  as  an  overview  of 
various  technical  issues  that  need  to  be  aadressed  _ 

arrive  at  a  detailed  description  of  FPLMTS,  to  be  used  for  FPLMTS 
program  management.  It  should  also  be  noted  that  the 
Responsibilities  shown  are  based  on  the  organizational  structure  of 
the  CCIR  and  CCITT  as  of  October  1992. 

The  detailed  structure  of  CCIR  or  CCITT  recommendations  explicitly 
on  FPLMTS  or  including  FPLMTS  issues  will  have  to  be  defined  by  th 
parties  responsible  for  their  production.  Further,  rf^should  be 
noted  that  although  an  identified  technical  issue  needs  to  be 
addressed,  there  are  no  assumptions  implied  the  need  to 

standardization  or  the  degree  of  standardization  for  the  particular 

technical  issue. 
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Figure  1:  FPLMTS  Program  (Conceptual) 
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Annex  1 

Milestones  for  the  overall  definition  of  FPLMTS 

First  overall  system  objectives  set  (CCIR  Rec  687)  : 

Initial  framework  of  services  defined  (CCIR  Rec  816) ; 
Network  architecture  defined  (CCIR  Rec  817) : 

Objectives  for  satellite  integration  set 
(CCIR  Rec  818) : 

Objectives  for  support  of  developing  countries  set 
(CCIR  Rec  819) : 

jr*  Spectrum  identified  by  WARC-92 

Initial  radio  interface  framework  defined: 

Initial  FPLMTS  spectrum  usage  principles  defined: 

F?L>!TS  traffic  requirements  defined: 

System  objectives  and  framework  finalized: 

Framework  of  ser'/ices  and  facilities  finalized: 
Security  principles  defined: 

Initial  FPLMTS  terminology  defined: 

Network  procedures  finalized: 

Radio  interface  signalling  requirements  defined: 
Network  interworking  scenarios  defined: 

Framework  for  satellite  integration  defined: 

Network  management  principles  defined: 

Choice  of  radio  access  principles: 

Choice  of  speech/Channel  coding  principles; 

Data  services  principles  defined: 

Detailed  security  requirements  defined: 

Initial  performance  requirements  defined: 

Speech  and  channel  coding  issues  defined: 

Physical  radio  access  structure  ready: 

Radio  interface  protocols  ready: 

Complete  audio  aspects  ready: 

Security  algorithms  ready: 

Video  coding  issues  defined: 

Network  protocols  ready: 

Data  sein/'ices  issues  ready: 

Detailed  network  management  requirements  ready: 

FPLMTS  terminology  finalized: 

Physical  radio  access  performance  ready: 

Complete  video  aspects  ready: 

Conformance  specifications  ready: 

Possible  start  of  service: 


Mid  90 

Mid  92 
Mid  92 

Mid  92 

Mid  92 
Mid  92 

Mid  93 
Mid  93 

End  93 

Mid  94 
Mid  94 
Mid  94 
Mid  94 

End  94 
End  94 
End  94 
End  94 
End  94 

Mid  95 
Mid  95 
Mid  95 
Mid  95 
Mid  95 

End  95 

Mid  96 

End  96 
End  96 
End  96 
End  96 

Mid  97 
Mid  97 
Mid  97 
Mid  97 

End  97 
End  97 

End  98 

2000  - 


2002 


•  6- 

8-l/TEMP/47(Rcv.l)-E 


»*»sss  =  s  =  s;-*««**^*s****®**®*****®***®******“®’^*“*®***“®********* 

FPIMTS  Rcspons i b i I i ty 5 

technical  area: 

.2._.S.5SSSS3SSSSSSSSSSSSSrSS«X«XCXSSSSSSXCCSrSSSSSSSXSSSBSSSSS] 

XAOIO  ASPECTS  (physical  layer  and  signalling) 


Franeworlc  of  radio  system 
Multiplexing  and  multiple  access 
Channel  coding 
Modulation 

Transmission  and  reception 
Physical  link  control 
Synchroni za t i on 
Radio  interface  protocols,  layer  1 
Radio  interface  protocols,  layer  2 
Radio  interface  protocols,  layer  3 


Overall  THN  framework 
P e r f crmanc e  management 
Fault  management 
Configuration  management 
Accounting  management 
Security  management 
End  user  profile  management 

audio  aspects  (detailed  descriptions) 

Speech  codecs  description 
Voice  Activity  Mechanisms 
Eero  control 

Transmission  requirements 

VIDEO  ASPECTS  (detailed  descriptions) 

Video  codecs  description 
Transmission  requirements 


CCITT  SGXV 
CCITT  SGXll 
CCITT  SGXII 


CCITT  SGXI 1 


TERMINAL  ASPECTS  (functional  requirements) 

Terminal  adaptation  functions  ’ 

security  aspects  (principles,  functions  and  detailed  descriptions) 


SXXSXX3XXKXXX 

To  be 
f inai i zed: 

srxxxxrxsxxxx 


TG 

8/1 

12/95 

TG 

8/1 

06/96 

TG 

8/1 

06/96 

TG 

8/1 

06/96 

TC 

8/1 

12/97 

TG 

8/1 

12/97 

TC 

8/1 

06/96 

TG 

8/1 

and 

CCITT 

SGXI 

12/96 

TG 

8/1 

and 

CCITT 

SGXI 

12/96 

TC 

8/1 

and 

CCITT 

SGXI 

12/96 

t  and  procedures) 

TC 

8/1 

and 

CCITT 

SCI  V 

12/94 

TC 

8/1 

and 

CCITT 

SGI  V 

06/97 

TG 

8/1 

and 

CCITT 

SCI  V 

06/97 

TG 

8/1 

and 

CCITT 

SGI  V 

06/97 

TG 

8/1 

and 

CCITT 

SGI  V 

06/97 

TC 

8/1 

and 

CCITT 

SGI  V 

06/97 

TG 

8/1 

and 

CCITT 

SCI  V 

06/97 

c: 

ITT 

SGXV 

12/95 

06/97 


Security  for  FPLMTS 

Security  algorithms  for  FPLMTS 


TC  8/1  and  CCITT  SGXI 
TG  8/1  or  national 


06/95 

12/96 


ATTACHMENT  2 


Documents  Document  8-l/TEMP/66,(Rev .  1) -E 

CCIR  Study  Groups  Palermo,  22  October  1992 

Period  1990-1994  English  only 


Task  Group  8/1 
DRAFT  OPINION 


The  CCIR, 

considering 

a)  that  the  CCIR  has  a  program  on  Future  Public  Land  Mobile 
Telecommunication  systems  (FPLMTS)  which  would  enable  worldwide, 
compatibilih'; 

b)  that  major  programs  for  future  mobile  communications  within  each 
Region  are  at  early  stages; 

c)  that  resources  of  budget,  manpower,  and  planning  expertise  are  available 
to  these  programs  which  substantially  exceed  those  readily  available  to  the 
CCIR; 

d)  that,  without  international  coordination,  these  regional  programs  would 
tend  to  diverge; 

e)  that  international  standards  for  future  mobile  communications  (i.e. 
FPLMTS)  will  not  be  effective  unless  these  regional  programs  are  harmonized; 

f)  that  the  production  of  CCIR  Recommendations  on  FPLMTS  will  be  an 
important  step  in  achieving  this  harmonization, 

is  of  the  opinion 

that  the  ITU,  as  a  matter  of  policy,  should  make  every  effort  to  persuade 
regional  and  national  authorities  to  support  the  CCIR  in  an  explicit  manner  in  its 
development  of  Recommendations  on  FPLMTS  and  strongly  encourage  regional 
organizations  to  work  together  towards  a  single  worldwide  standard. 
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Working  Document 

CONSIDERATIONS  ON  THE  RELATIONSHIP  BETWEEN  FPLMTS  AND  UPT 


1.  General 

UPT  is  a  se^ice  concept  that  is  provided  by  a  UPT  service 
provider  which  in  principle  may  be  different  from  the  FPLMTS 
service  provider.  This  does  not  preclude  that  a  FPLMTS  service 
provider  also  may  be  a  UPT  service  provider,  and  vice  versa. 

FPUfTS  supports  UPT,  and  thus  provides  mobile  access  to  UPT  users, 
which  logically  are  different  from  FPLMTS  users.  A  UPT  user  is  a 
FPLMTS  user  by  default  when  accessing  FPLMTS,  but  does  not 
necessarily  have  to  be  associated  with  a  regular  FPLMTS 
subscriber.  Conversely,  a  FPLMTS  user  does  not  need  to  be  a  UPT 
user. 

2.  Mobility  and  Portability  Concepts 

Simply  by  being  a  radio  system,  FPLMTS  will  have  the  possibility 
to  provide  "terminal  mobility".  In  addition,  FPLMTS  supports  UPT 
with  the  inherent  "personal  mobility"  offered  by  UPT. 

Further,  FPLMTS  should  have  the  possibility  for  connecting 
standard  Terminal  Equipments  (TEs)  to  FPLMTS  Mobile  Terminations 
(MTs) ,  thus  providing  "standard  terminal  portability".  A  FPLMTS 
Mobile  Termination  is  the  part  of  the  FPLMTS  Mobile  Station  which 
terminates  the  radio  path  at  the  mobile  side  and  adapts  the 
capabilities  of  the  radio  path  to  the  capabilities  of  the  terminal 
equipment . 
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An  additional  feature  which  is  being  considered  for  FPI2ITS  is  the 
"FPLMTS  user  mobility".  The  FPLMTS  user  mobility  is  a  feature 
offered  by  FPIMTS  simply  because  the  FPLMTS  user,  and  its 
associated  FPLMTS  subscription,  may  be  physically  separated  from 
the  FPLMTS  terminal  (e.g.  with  some  form  of  a  smart-card). 

There  are  various  advantages  in  physically  separating  the  FPIWTS 
user  from  the  FPLMTS  terminal,  including: 

*  The  FPLMTS  user  will  have  some  form  of  discrete  mobility 
between  Mobile  Stations,  the  "FPLMTS  user  mobility". 

*  The  security  involved  in  the  FPIMTS  services  are  substantially 
improved,  for  the  FPLMTS  users  and  subscribers  as  well  as  the 
FPLMTS  operators  and  service  providers. 

There  is  much  greater  flexibility  for  the  FPLMTS  services 
providers  in  handling  the  FPLMTS  users,  and  much  greater 
flexibility  for  the  FPLMTS  users/subscribers  to  change  FPLMTS 
service  providers. 

*  The  FPLMTS  Mobile  Station  market  will  be  more  open  since  there 
.are  no  requirements  for  associating  a  Mobile  Station 

physically  to  a  subscription. 

3.  Numbering,  Identification  and  Addressing 

It  may  be  appropriate  to  separate  the  identification  of  FPLMTS 
users  and  the  FPLMTS  Mobile  Terminations.  This  gives  the  FPLMTS 
networks  the  possibility  to  address  FPLMTS  users  and  FPLMTS 
terminals  independently,  as  appropriate,  depending  on  the  choices 
of  the  FPLMTS  subscriber  or  service  provider.  It  also  simplifies 
the  handling  of  UPT  users  accessing  the  FPLMTS  network,  as  the  UPT 
user  identity  simply  may  be  associated  directly  with  the  FPLMTS 
Mobile  Termination  identity. 

The  FPLMTS  users  and  the  FPLMTS  Mobile  Terminations  are  always 
logically  separated,  but  there  is  still  the  option  to  have  the  two 
physically  integrated  into  one  equipment,  if  this  is  desired. 

Concerni.ng  numbering  for  FPLMTS,  a  FPLMTS  user  will  always  have  a 
dialable  "FPLMTS  Number",  with  which  the  calling  parties  can 
reach  the  FPLMTS  users.  A  FPLMTS  number  may  be  mapped  on  to  a 
FPLMTS  Mobile  Termination  identity  or  to  a  FPLMTS  user  identity, 
depending  on  the  agreer.ents  set  up  at  subscription  time  between 
the  FPLMTS  service  provider  and  subscriber. 

One  objective  of  FPLMTS  is  that  it  should  support  Universal 
Personal  Telecommunication  (UPT) .  This  means  that  a  UPT  user  can 
access  service  via  the  FPLMTS  network,  by  using  his  "UPT  Number". 
There  is,  however,  no  requirement  that  a  F?L^;TS  user  needs  to  have 
a  UPT  number  (or,  in  other  works,  needs  to  be  a  UPT  user).  If, 
however,  a  FPLMTS  user  also  is  a  UPT  user,  he  may  be  reached  by 
calling  parties  via  FPlMTf  by  the  use  of  his  FPLMTS  Number  and  his 
UPT  Number,  as  appropriate. 

The  FPLMTS  Number,  whether  :r.  is  usee  fer  FPLMTS  Mobile 
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Terminations  or  for  FPWrrs  users,  will  have  approximately  the  same 
requirements  on  the  nximbering  plan  as  the  UPT  Number.  Therefore, 
the  numbering  plan  appropriate  for  the  FPLMTS  Number  is  also  CCITT 
recommendation  E.168. 

The  mobility  and  portability  concepts  involved  with  FPLMTS  and  UPT 
are  illustrated  in  fig  i,  together  with  the  numbers  and  identities 
foreseen. 


FPLMTS 

Mobile 

Station 


Personal  FPLMTS  Terminal 

mobility  user  mobility 

(UPT)  mobility  (FPLMTS) 

(FPLMTS) 


Fig  1,  FPLMTS  and  UPT  mobility/portability  concepts  and  related 
numbers  and  identities. 


4,  Agreements  reached  at  June  1993  TG  8/1  meeting 

The  following  agreements  were  reached  at  the  June  1993  joint  meeting  of  WG  III 
WG  IV  and  other  interested  TG  8/1  participants.  Text  based  on  these  agreements  is 
required  for  inclusion  in  this  working  document. 
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_ a)  Subsciiption  to  UPT  and  FPLMTS  are  independent,  i.e..  an  FPLMTS  user 

may  optionally  subscribe  to  UPT  and  a  UPT  user  mav  or  mav  not  be  an  FPLMTS  user, 

_ b)  The  terminal  identity  and  user  identity  are  logically  separated.  They  may 

optionally  be  physically  separated,  thereby  proyidina  FPLMTS  user  mobility. 

_ c)  FPLMTS  yyill  require  a  diallable  number  (FPLMTS  numberV  This  number 

should  conform  to  E.164  with  characteristics  similar  to  UPT  (E.168).  FPLMTS  numbers  will 
be  associated  vyith  FPLMTS  user  IDs  fin  the  case  of  FPLMTS  user  mobility)  or  with  the 
FPLMTS  terminal  tin  the  case  of  the  user  ID  logical  entity  being  physically  combined  with 
the  terminal  ID  entity  in  the  terminalV  This  matter  needs  to  be  further  considered  by 
TS  SG  2. 

_ d)  FPLMTS  subscription  is  associated  with  an  FPLMTS  user,  not  an  FPLMTS 

terminal 


ANNEX  1 


Vocabulary 


*  FPLMTS  user:  A  person,  entity  or  process  actually  using  the 
FPLMTS  services.  A  FPLMTS  user  is  associated  with  a  unique 
FPLMTS  user  identity. 

*  FPLMTS  subscriber:  A  legal  person  or  entity  associated  with 
the  FPLMTS  subscription  and  responsible  for  the  charges 
incurred  by  his  associated  FPLMTS  users,  if  any.  A  FPLMTS 
subscriber  may  be  responsible  for  several  FPLMTS  users. 

*  FPLMTS  service  provider;  A  legal  person  or  entity  responsible 
for  providing  FPLMTS  subscriptions  to  FPLMTS  subscribers. 

*  FPLMTS  operator:  A  legal  person  or  entity  ultimately 
responsible  for  providing  complete  FPLMTS  network 
functionality  to  FPLMTS  users.  Parts  of  the  complete  FPLMTS 
network  functionality  may,  however,  be  provided  by  other 
parties. 

*  UPT  user:  A  user  using  UPT  services,  and  which  is  associated 
with  a  UPT  subscriber  and  UPT  service  provider. 

*  UPT  subscriber:  The  subscriber  associated  with  a  UPT  user.  A 
UPT  subscriber  subscribes  to  a  UPT  service  prov'ider. 

*  UPT  service  provider:  A  legal  person  or  entity  responsible 
for  providing  UPT  subscriptions  to  UPT  subscribers. 
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GUIDANCE  FOR  THE  WORK  OF  THE 
RAPPORTEUR  FOR  THE  VIDEOPHONE 
PART  OF  OUESTION  2/15 


ANNEX  B 


Temporary  Document  TD_  (15/1) 

STUDY  GROUP 

WORKING  PARTY  15/1 

Geneva,  6-17  September  .1993 

Guidance  for  the  Work  of  the  Rapporteur  for  the  Videophone 
(Very  Low  Bitrate)  Part  of  Question  2/15 

Source:  Chairman  of  Working  Party  15/1 


1.0  Introduction 

At  a  meeting  on  6-17  September  1993,  Working  Party  15/1  re¬ 
appointed  a  Rapporteur  for  Very  Low  Bitrate  Visual  Telephony.  The 
purpose  of  this  document  is  to  define  the  guidelines,  requirements, 
objectives  and  work  method  for  the  work  of  the  Rapporteur. 

The  Rapporteur  presented  a  report  (TD  7)  at  the  6-17  September 
meeting  outlining  work  accomplished  since  the  last  meeting, 
tentative  technical  conclusions,  and  a  recommended  work  plan.  This 
report  may  be  used  as  general  guidance  for  the  Rapporteur '  Jr  work, 

subject  to  the  particular  requirements  and  objectives  outlined 
below. 


2.0  Ob~iectives 

c  The  objective  is  to  develop  two  sets  of  draft  ITU-TS 
Recommendations  for  Very  Low  Bitrate  Visual 
Telephony.  The  first,  (H.VLC/N),  employing  near 
term  technology  would  be  finalized  in  1995.  The 
second,  Recommendation  (H.VLC/L)  employing  more 
advanced  technology,  would  be  finalized  in 
approximately  1998. 

H.VLC/N  will  consist  of  a  number  of  Recommendations 
for  major  functional  elements  of  the  videophone 
system  such  as  those  noted  below: 

-A  Videophone  System  Operating  at  a  Very  Low  Bitrate 
(H. 32P) 

-Video  Coder  for  The  Very  Low  Bitrate  Videophone 
(AV, 263) 

-Speech  Coder  for  The  Very  Low  Bitrate  Videophone 
-.Multiplex/Error  Control  for  The  Very  Low  Bitrate 
Videophone  (H.22P) 

—Supervisory  Control  for  The  Very  Low  Bitrate  Videophone 
(H.42P) 

-Data  Interface  for  The  Very  Low  Bitrate  Videophone 
-PSTN  Modem  for  The  Very  Low  Bitrate  Videophone 
(V.32bis,  V.34/V.3{V.FAST}) 


H.VLC/L  will  include  additional  Recommendations  in 
technical  areas  requiring  more  time  to  develop  such 
as : 

-  Advanced  Video  Coding 

-  Advanced  Speech  Coding 

-  Operation  Over  The  Future  Public  Land  Mobile 
Telecommunications  System  (FPLMTS) 

o  H.VLCN  must  be  prepared  for  the  future  and  must 
pave  the  way  for  H.VLC/L  in  such  a  way  that  the 
transition  from  the  near  term  to  the  long  term 
standard  will  be  relatively  easy.  Backward 
compatibility  is  required. 

o  Follow  the  guidance  from  SG  1  outlined  in  their 
TD  27  Liason  Statement.  (Annex  A) 

o  Follow  the  guidance  from  SQEG  outlined  in  TD  28. 
(ANNEX  B) 

o  As  an  objective,  an  optional  data  channel 

would  be  included  to  be  multiplexed  with  the 
audio  and  video  signals.  Provision  for  high 
resolution  still  images  using  the  JPEG  standard  . ^ 
will  be  provided.  1+  ‘X  r w <  w  rrv> 

O-H-iev  r  1  T"*  4^  ITU  R  -6  . 

o  The  speec.h  coder  objective  for  H.VLC/N  is  to 

achieve  as  near  toll  quality  as  possible  given 
the  bit-rats  budget.  In  long  term  H.VLC/L  it  is 
expected  to  achieve  toll  quality  at  4kbps.  This 
work  has  been  referred  to  the  speech  experts 
wit.hin  Working  Party  15/2 

o  The  objective  for  H.VLC/N  is  to  achieve  a  picture 
quality  significantly  better  than  H.261  when  oper¬ 
ating  with  the  corresponding  parameters. 

o  The  objective  for  H.VLC/L  is  to  achieve  picture 
quality  considerably  better  than  H.VLC/N. 

o  P^ull  ^  In  nnt/i  Ir' f' 

3 . 0  Requirements 


o  Concidoi-’acioH  for  multi-point  operation. 

o  A  flexible,  robust  multiplex  structure  to  maximize 
the  utility  of  the  available  transmission  bit  rate. 

o  Use  of  V.32bis  and  V.FAST  modem  technology  for 

H.VLC/N  to  maximize  the  transmission  bitrate  while 
providing  adequate  error  resilience. 

1  loil/iy  U/ ;  ft,  M-  SCld  rxa, 


4 . 0  Work  Method 


In  order  to  achieve  good  results,  the  Rapporteur 
will  convene  experts  wishing  to  contribute  to  the 
work. 

Work  should  be  accomplished  through  correspondence  as 
much  as  possible. 

The  Meeting  of  Experts  between  meetings  of  the  WP 
15/1  must  be  approved  by  the  WP  15/1. 

The  Rapporteur  must  coordinate  the  work  with  other 
Study  Groups  and  other  appropriate  standards  bodies. 
Study  Group  15  will  transmit  official  requests  for 
cooperation  to  other  Standards  Groups  and  Standards 
Bodies  when  required. 

Work  jointly  with  SG  l  to  develop  a  detailed  set  of 
Technical  Requirements  for  all  functional  elements  of 
the  Very  Low  Bitrate  Videophone. 

Collaborate  with  ISO/IEC  JTC  1/SC29  WGll  (MPEG4), 
ocularly  in  the  area  of  advanced  video  coding. 

The  Rapporteur  will  provide  progress  reports  at  all 
meetings  of  Study  Group  15  and/or  Working  Party 
15/1. 
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Video  Coding  in  Mobile  Networks  -  Some  Aspects 
BOSCH  C/FOH  and  LENT  Aachen  ^ 

Discussion 


1  Introduction 

Mobile  telecommunicatiog  is  of  increasing  importance.  This  point  of  view  is  jnstined  by 
the  development  of  the  European  Universal  mobile  telecommunication  System  (UMTS) 
[1]  headed  by  ETSI  STC  SMG5.  Comparable  work  is  performed  internationally  by  ITU-R 
TG8-1  responsible  for  the  standardization  of  the  Future  Public  Land  Mobile  Telecommu¬ 
nication  Systems  (FPLMTS)  [2j.  These  networks  will  be  used  as  a  basis  for  all  mobile 
teiecomxnunication  services  by  the  year  2000.  The  proposed  range  of  aoplications  can  be 
described  as  multimedia  services.  Thus  within  these  networks  video  transmission  will  be 
only  one  possible  service.  One  important  project  in  this  context  is  the  European  RACE 
project  M.A.VT  H.2072  currently  developing  a  first  mobile  audio-video  terminal  [3). 

The  picture  quaiitv*  of  future  video  services  must  be  significantly  better  than  the 
qualir/  of  current  codecs.  Thus  high  sophisticated  video  coding  algorithms  are  necessary 
to  meet  the  demand  for  verv  hish  aualitv.  This  tarzet  is  verv  close  to  that  of  MPEG- 
4.  so  MPEG-4  can  be  seen  as  a  possible  video  coding  standard  used  within  the  UMTS 
i.rPLMTS).  Further  the  time  schedule  is  well  adjusted.  .4.3  a  result  MPEG-4  chips  will 
be  the  first  choice  for  UMTS. 

Since  there  are  basic  differences  between  mobile  networks  and  fixed  networks,  mobile 
aspects  should  be  considered  in  the  development  of  novel  video  coding  algorithms  in 
MPEG-4  from  the  beginning. 

2  Mobile  Aspects 

There  are  mainly  two  differences  between  mobile  and  stationary  video  communication; 

•  image  material 

•  transmission  aspects 
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2.1  Scenes  in  a  Mobile  Environment 

In  mobile  environments  there  are  no  restrictions  of  the  scenes  to  be  transmitted  to  some 
purposes.  The  scenes  are  much  more  complex  than  those  currently  assumed  in  fixed 
necworks  at  very  low  it  rates,  e.g.  Miss  America  or  Salesman.  The  characteristics  of  the 
image  material  can  be  summarized  as  follows: 

moving  camera  :  zoom,  pan,  vibration,  auto  focus 

motion  types  :  •  strong  movements  possible 

•  motion  in  the  background  ^ 

•  much  stronger  motion  in  the  3D  space  compared  to  video  con¬ 
ference  like  scenes 

Thus  there  are  a  lot  of  regions  with  highly  varying  motion. 

objet  types  :  arbitrary  objects,  highly  structured  backgroimd 

scene  cuts  :  or  scene  cut  like  situations  characterized  by  very  fast  pan  and/or 

rapidly  changing  background 

outdoor  scenes  :  iiluminadon  changes,  varying  contrast,  whether  conditions  as  rain, 

mist,  snow,  etc. 

noise  :  camera  noise 

2.2  Transmission  Aspects 

In  hxed  telecommunication  networks  the  error  probability  on  the  transmission  links  is 
very  small  {P.  ^  10~*).  Thus  using  error  correcting  codes  an  almost  error  free  data 
transmission  is  possible. 

However  in  mobile  channels  an  error  free  data  transmission  can  not  be  guaranteed. 
Thus  the  coder  must  consider  the  current  channel  characteristics  to  enable  a  reliable  data 
transmission.  As  a  result  the  coder  is  influenced  by  the  channel. 


■'•Vhat  SDOuid  be  the  de.nnitior.  of  background  if  no  dominant  object  is  present? 
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In  the  following  some  important  aspects  are  listed  : 

chjLnnel  characteristics  : 

time  and/or  frequency  selective  fading,  burst  errors 

channel  capacity  : 

•  only  small  channel  bandwidth 

•  Due  to  the  varying  error  probability  a  stationary  or  even  fixed  net 
channel  capacity  can  not  be  assxuned. 


several  channels  : 

To  ensure  a  target  picture  quality  more  than  one  channel  might  be 
necessary.  This  introduces  additioncd  problems  as  how  to  distribute  the 
information  over  the  channels  and  to  achieve  a  stable  transmission. 

bit  error  sensitivity  : 

Some  types  of  symbols  are  more  sensitive  to  bit  errors  than  others. 
More  signincant  information  needs  a  higher  error  protection  than  less 
significant  information  [4]. 

synchronization  : 

•  As  a  result  of  not  correctable  errors  coder  and  decoder  will  lose 
synchronization. 

•  There  mighc  be  a  loss  of  data  bits  e.g.  in  case  of  handover. 


3  Prerequisites  for  Video  Coding  Algorithms 

The  described  characteristics  of  the  image  material  and  the  transmission  lead  to  conditions 
a  video  coding  algorithm  should  fulfill. 

•  Concerning  the  image  material  model-based  approaches  assuming  special  types  of 
scenes  as  e.g.  head  and  shoulder  scenes  might  not  be  the  best  solution. 

•  Complex  motion  models  are  necessary  to  cope  e.g.  with  different  overlaid  types  of 
motion. 

•  Scene  cuts  and  similar  situations  must  be  detectable,  because  temporal  prediction 
might  fail. 

•  Due  to  the  varying  net  channel  capacity  the  coding  algorithm  should  be  able  to 
generate  different  bit  rates  as  close  as  possible  at  the  rate-distortion  bound  for  each 
generated  rate. 
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•  To  meet  the  requirement  of  high  quality  even  if  the  net  channel  capacity  is  low 
(high  error  probability)  the  coder  should  be  able  to  use  more  than  one  channel. 
A  multi-resolution  approach  might  be  a  solution  with  a  very  high  error  protection 
in  the  base  layer  to  avoid  losing  significant  information  necessary  for  decoding  the 
additional  layers. 

•  The  selection  of  the  information  to  be  coded  might  consider  the  dependency  between 
different  types  of  symbols;  e.g.  in  current  algorithms  if  there  in  an  error  in  a  motion 
vector  the  DCT-coeffidents  for  that  block  are  useless. 

•  It  can  be  assumed  that  there  will  be  some  status  information  firom  the  decoder 
available  at  the  coder.  ^ 

•  A  coder  -  decoder  resynchronization  is  necessary.  That  means  that  the  type  of 
coded  information  may  be  influenced  by  the  decoder! 


4  Conclusion 

The  increasing  importance  of  mobile  networks  (UMTS)  requires  the  consideration  in  the 
deveiopmenc  of  novel  video  coding  algorithms.  The  close  relation  between  the  topics  of 
MPEG-4  and  UMTS  seems  to  favour  the  coming  MPEG-4  video  coding  algorithm  for 
usage  in  UMTS. 

The  oaner  tried  to  Doint  out  some  imnortant  asoects  of  mobile  networks  and  to  give 
guidelines  for  the  development  of  video  coding  algorithms  useful  in  these  networks. 
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1  Introduction 

The  current  situation  in  the  field  of  very  low  bit  rate  video  coding  shows  uncertanties 
about  the  applications  low  bit  rate  coding  should  be  used  for.  On  the  one  hand  there  is 
the  PSTN  videophone.  For  this  application  a  video  coding  algorithm  has  been  developed 
in  COST211ter  [ll.  But  there  are  aJso  devices  (AT&sT,  Marconi)  already  on  the  market. 
On  the  other  hand  a  mobile  videotelephony  hardware  is  currently  under  development  in 
the  R-A.CE  project  R2072  MAVT  (see  related  paper). 

.although  all  coding  schemes  under  consideration  use  a  DCT-based  hybrid  DPCM  loop 
and  therefore  the  same  type  of  data  is  coded,  the  data  stream  structures  are  partly  or 
even  completely  incompatible  (fig-l). 


Fig’ure  1:  Compatibility  of  low  bit  rate  videocoding  algorithms 

Thus  to  achieve  interoperability  one  has  to  make  compromises  or  one  might  need 
switching  devices  as  e.g.  in  ISDN  -  PSTN  connections.  These  solutions  can  introduce 
serious  problems  in  the  future,  because  there  is  a  fast  development  of  services  and  demands 
in  the  area  of  telecommunication.  .Additionally  the  rapid  development  in  the  area  of  mobile 


'coQcaci  D.Lappe  or  Kl-Illgner 


.  LBC-93-069 


Proposal  for  a  GEiVERic  data  stream  structure 


2 


Projects  and  Devices 


Standards 
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digital  analog 


mobile  network 
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digital  auialog 


mobile 


Fig’ire  2:  Evolucion  of  low  bit  rate  videocoding  standards  and  devices 

leiecommunication  (UMTS)  should  be  considered.  These  problems  can  be  avoided  by 
(denning  more  flexible  standards  assuming  one  t3/pe  of  applications  as  e.g.  video  coding 
via  point-to-point  links.  The  main  intention  shouia  oe  that  encoder  and  cecoder  agree 
upon  coding  parameters  and  transmit  the  coded  data  with  a  generic  structure. 

One  steo  towards  more  flexible  video  coding  standards  is  the  deflnition  of  a  generic 
data  stream  structure.  It  should  have  the  capability  to  include  all  known  data  structures 
and  must  consider  specific  problems  of  target  applications  as  e.g.  mobile  communication. 
For  future  demands  the  data  structure  in  question  should  additionally  allow  more  sopni- 
sticaced  coding  algorithms  as  e.g.  region  oriented  cooing  scnemes  and  hierarchical  coding 

(?-g- 

2  Current Iv  used  data  structures 

In  current  block  based  video  coding  algorithms  the  symbols  to  be  coded  are  the  motion 
vectors  and  the  DCT-coefficients  for  each  block  or  macroblock.  Additionally  there  axe 
overhead  bits  for  the  coder  control  signalling  e.g.  the  update  mode  (INTER/INTRA). 
There  axe  two  main  possibilities  for  multiplexing  of  these  symools  into  one  viaeo  data 
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picture  layer: 


MBLK  layer; 


CMP  VLC  mode  information  and  description  which,  blocks  are  coded 
motion  VLC  motion  vectors  of  the  macroblock,  horizontally  predicted 
DCT  VLC  quantized  DCT-coefficients  of  the  coded  blocks  (see  CBP) 

Figure  3:  Multiplexing  of  the  symbols  in  the  H-261 

stream.. 

2.1  Sequential  Multiplexing 

This  scheme  is  used  in  the  H.26I  [2j  and  in  the  COST  21  Iter  Simulation  model  [Ij.  AH 
data  for  one  macrobiock  is  coilected  and  transmitted.  In  the  so-called  macroblock  layer 
(MBLK  layer)  first  some  codewords  signal  what  has  been  coded  lor  that  macroblocx.  In 
the  second  par*  the  motion  vectors  followed  by  the  DCT-coemc:ents  are  transmitted.  The 
macroblocks  are  processed  sequentially  (fig.  3). 

•An  advantage  is  that  coding  and  decoding  may  be  done  just  in  time  introducing  only 
small  coding  delay.  Another  advantage  could  be  less  storage  requirements.  The  disadvan- 
taee  of  this  concept  is  that  an  adantation  to  global  characteristics  is  hardly  possible.  Each 
macroblock  is  handled  more  or  less  independently  from  the  other  macroblocks.  Thus  it  is 
difficult  to  implement  e.g.  a  region  oriented  scheme. 

The  characteristics  of  mobile  channels  is  completely  different  compared  to  stationary 
channels.  One  aspect  is  the  error  probability.  In  the  ISDN  the  worst  case  error  rates  are 
2=  10“'’ . . .  10“'  whereas  in  mobile  channels  burst  errors  with  rates  up  to  2:  10“' . . .  10“^ 
must  be  considered  [4].  Thus  in  mobile  videophones  the  error  protection  has  to  be  adapted 
to  the  different  bit  error  sensitivities;  e.g.  motion  vectors  are  more  sensitive  than  coded 
DCT-coemcients  and  require  therefore  more  error  protection. 
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Figure  4:  Multiplexing  in  MAVT 

2.2  Global  Multiplexing 

In  the  alternate  scheme  which  is  used  in  the  MAVT  videophone  (fig.  4)  all  data  of  one  type 
is  collected  for  the  whole  picture  and  transmitted  as  one  block.  Thxis  first  the  complete 
displacement  vectorfield  is  transmitted  and  in  the  second  block  the  update  information. 

This  concept  of  data  partitioning  allows  independent  error  correction  on  varioi^  types 
of  data.  Further  a  more  efficient  coder  control  is  possible,  because  all  data  for  coffing  of  a 
complete  Image  is  available  at  once.  So  one  can  optimize  the  update  information  in  terms 

of  the  available  bitrate.  -  j  i 

The  main  disadvantage  is  a  slightly  greater  storage  requirement  and  a  coder  delay  of 

at  least  one  picture. 


3  Prerequisites 

The  de.finition  of  a  generic  data  stream  structure  has  to  consider  current  data  stream 
structures.  Further  the  requirements  for  mobile  environments  must  be  taken  into  account. 

It  is  expected  that  for  mobile  ■'ddeophones  at  least  two  channels  each  with  a  net  bitrate 
of  9.6  kbps  are  necessary  to  meet  the  quality  requirements.  Therefore  the  coding  structure 
should  be  based  on  a  layered  scheme. 

The  video  coding  algorithm  must  be  able  to  adopt  to  variable  net  bitrates  on  the 
channel.  Thus  the  data  stream  structure  has  to  consider  scalable  coding  schemes. 

**  ?or*fucure  demands  (MPEG  IV  ?)  region  oriented  codecs  should  be  able  to  use  the 

same  data  stream  structure. 

The  requirements  to  consider  are  summarized  as  follows: 


•  capabilittr  for  interworking  with  the  H.261  data  stream  structure  (no  transcoding, 
only  reformatting) 

•  stabiiitv  against  burst  errors  whicn  occur  in  mobile  channels 

•  scalability  -  nearly  optimal  penormance  at  different  bitrates 

•  dynamic  channel  allocation  -  layered  coning 

^The  terms  layered  and  scalable  coding  are  not  well  de.nned.  Thus  m  the  conte.xt  of  this  paper  layered 
coding  means  refinement  only  of  the  resolution  using  seperate  data  streams.  Scalability  mostly  has  the 
meaning  of  partially  decodeable  data  streams,  but  stands  in  that  paper  for  the  generation  of  varying  bit 
rates  with  nearly  optimal  performance. 
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•  support  of  region  oriented  coding  schemes 

•  fast  picture  startup  mode  •  necessary  e,g.  in  case  of  severe  channel  errors 


4  A  generic  Data  Stream  Structure 


The  global  multiplexing  scheme  is  better  suited  for  mobile  environments  and  is  more 
flexible  to  meet  the  prerequisites.  Thus  we  propose  as  a  generic  data  stream  structure  an 
extension  of  the  global  multiplexing  used  in  MAVT. 

Between  the  picture  startup  code  and  the  motion  information  a  block  describing  the 
coded  regions  is  inserted  (fig.  4,5).  The  idea  behind  this  is  that  only  regions  itself  and 
their  associated  motion  and  update  information  should  be  coded. 


M 


address 


r 

V. 


motion 


Figure  5:  Extended  multiplexing 


4.1  Description  of  the  parts 

The  picture  startup  code  (fig.  6)  handles  general  information  valid  for  one  frame,  e.g. 
biock  or  region  oriented  coding.  The  modes  for  motion  compensation  (e.g.  displacement 
vectors  or  parametric  motin  decription)  and  update  coding  (e.g.  DCT,  subband  coding) 
are  signalled  here.  too.  Special  update  information  globally  valid  as  e.g.  the  quantizer 
stepsize  can  also  be  included  here.  Further  one  could  think  about  VLC-codewords  signal¬ 
ling  one  set  of  modes  instead  of  coding  each  mode  separately. 

In  the  address  part  (fig.  7)  the  shape  and  position  of  each  coded  region  is  transmitted. 
.Also  the  update  mode  for  that  region  can  be  signalled,  if  the  desired  mode  is  different  to 
the  global  mode.  First  the  position  of  the  region  to  be  coded  is  transmitted.  This  can  be 
the  upper  left  corner  of  a  surrounding  rectangle  relative  to  the  previous  region  position. 
The  coding  method  for  the  shape  is  still  open  because  efficient  lossless  contour  coding 
schemes  are  very  expensive  compared  to  the  available  bitrate.  Lossy  coding  via  spline 
approximation  seems  to  be  more  promising  than  chain  codes.  However  this  approach 
introduce.*;  additional  problems  in  case  of  layered  coding. 

Block  oriented  coding  is  handled  by  coding  the  number  of  skipped,  that  means  not 
coded,  blocks  assuming  a  sequential  scanning  in  the  position  codeword.  This  replaces  the 
COD  bit  from  the  COST  211ter  Simulation  model.  Thus  each  block  is  regarded  as  one 
region.  No  shape  information  needs  to  be  coded.  If  the  type  of  motion  or  update  mode 
differs  from  the  global  mode  the  locally  used  modes  are  signalled  in  the  coding  mode 
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Figure  6:  extended  picture  code  (pic  code) 
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•(position) - (  CMP  ) - L^SHAPe) 


Figure  7;  Multiplexing  witiiin  the  address  part 


EOR  End  of  region 

Figure  8:  Multiplexing  witiiin  the  motion  and  update  part 

pactem  (CMP)  codeword.  Thus  one  can  switch  within  one  frame  between  parametric 
motion  description  or  displacement  vectors  and  between  DCT-coding  or  subband  coding. 

The  motion  information  coded  next  may  be  motion  parameters  or  a  displacement 
vectorneld.  If  displacement  vectors  are  used  as  motion  information  they  are  predicted 
only  within  the  associated  region,  not  across  the  region  boundaries.  In  this  block  all 
motion  information  is  stored  seouentiallv  but  onlv  for  those  regions  for  which  motion 
information  has  been  signalled  in  the  address  part.  Additionally  one  could  agree  in  case 
of  block  oriented  coding  upon  that  the  motion  vectors  are  not  the  original  motion  vectors 
but  are  predicted  from  the  neighbored  vectors  (DPCM  instead  of  PCM). 

Coding  of  the  update  information  only  associated  with  one  region  is  easily  possible. 
The  same  principle  for  arranging  the  update  information  as  for  the  motion  information 
is  used.  No  further  considerations  have  to  be  made  in  case  of  transform  coding.  Using 
a  hierarchical  coding  scheme,  e.g.  a  pyramid,  the  update  information  must  be  e.xtended 
by  a  number  signalling  the  layer  of  the  pyramid.  This  can  be  done  by  appending  a 
second  update  block  for  the  second  layer  just  behind  the  first  update  block.  However 
an  independent  layered  coding  as  described  below  seems  to  be  more  suitable.  Subband 
coding  is  also  possible  regarding  one  subband  as  one  layer.  Within  each  subband  only  the 
spatial  region  corresponding  to  the  region  in  question  is  coded, 

4.2  Extensions 

Independent  layered  coding  can  be  implemented  by  using  the  same  data  structure  (fig. 
5).  The  administration  information  and  the  region  information  is  coded  in  the  base  layer. 
The  second  layer  is  transmitted  in  the  following  frame  starting  again  with  a  pic  code.  The 
numbe  of  the  coded  layer  is  signalled  in  the  picture  startup  code.  Assuming  that  there 
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is  no  motion  information  in  the  second  layer  one  can  skip  the  region  block  as  well  as  the 
motion  block  and  can  just  transmit  a  second  update  block.  The  refinement  information 
can  be  a  more  detailed  region  description  considering  the  already  known  description. 
.A.Iso  one  can  code  just  a  second  update  block  containing  additional  pyramid  layers  or 
bandpasses.  But  even  a  more  detailed  motion  description  is  possible  by  signalling  this  in 
the  “second”  picture  startup  code. 

If  necessary  even  nearly  the  original  data  stream  structure  of  e.g.  COST  can  be  genera¬ 
ted  by  coding  only  the  first  macroblock  in  the  “first”  picture  layer.  The  next  macroblock 
is  coded  in  the  “second”  pictiire  layer  and  so  on.  The  disadvantage  of  a  lot  of  picture 
startup  codes  may  be  solved  by  using  only  one  bit  for  signalling  whether  there  is  another 
layer  or  not- 

The  structure  can  be  refined  by  introducing  a  sequence  startup  code  as  in  MPEG  [5]. 
In  general  there  must  be  a  handshake  procedure  at  the  beginning  of  a  video  session.  This 
handshake  procedure  includes  the  transmission  of  mode  and  update  information  valid  for 
one  sequence.  Thus  there  can  be  a  reduction  of  bits  necessary  for  administration. 

5  Conclusion 

In  the  paper  a  proposal  for  a  generic  data  stream  structure  is  described.  A  common 
and  dexibie  data  stream  structure  is  very  important  because  there  will  be  a  fast  deve¬ 
lopment  of  services  and  demands  in  the  area  of  mobile  teiecommuni cations.  Thus  it  is 
impossible  to  fix  a  specific  data  structure  and  simultaneously  fuinll  future  demands  of 
compatibility  with  existing  devices.  .A.  dexible  data  stream  structure  can  handle  a  broad 
variety  of  applications.  The  coder  and  decoder  will  .hnaily  agree  upon  what  actually  will 
be  transmitted. 

It  can  be  expected  that  future  mobile  videocodecs  contain  a  motion  estimation  and 
.mccicn  compensation  part  and  a  part  for  coding  the  residual  image.  For  example  the 
anaiysis-synchesis  coding  developed  at  University  of  Hannover  [3j  and  introduced  at  COST 
21  Iter  and  MPEG-4  as  a  starting  point  for  the  development  of  future  coding  schemes  can 
be  handled  by  that  data  stream  structure. 

Thus  the  proposed  data  stream  structure  might  be  useful  even  for  the  future  coding 
scheme  developed  by  MPEG-4.  Within  the  project  R.ACE  .VIAVT  this  data  stream  struc¬ 
ture  is  expected  to  be  used. 
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7.S07.  T.sn.  T.8I3,  T.317,  T.S20  !>U:  MobUe  Cananumeatioa* 

PL4:  Inuge  Cammunicatioxu 


Main  Objectives 

The  project  objecave  is  to  iiad  powerful  rideo  snd  ssdlo 
coding  ligohthnu  for  dve  aansmissIoQ  of  moving  and  still 
video  in  a  mobile  environfflot  (IDce  UMTS),  and  implencu 
then  on  a  denonstratcr.  Tliis  neeesitaiea  a  study  oi  user  re¬ 
quirements,  aetworic  and  channci-charammstics,  scvice 
ienniuons  and  a  general  tenainai  arrhitfcagc.  The  project 
'jviil  deliver  future  aigorithms  Tor  low  bitrate  video  (px  Sh 
bii/s)  and  audio  and  a  hituhstic  terminal  with  several 

novel  reacures,  including  a  vahabic  resolution  display  snd 
good  quality  audio.  New  proposals  for  '/LSI  chips  for  ’ddeo 
and  audio  coding  are  expec’^ed  iom  reaiisauon  of  ±c 
denensmtor. 

Technical  .approach 

roilowbg  deveiopenent  of  the  pxSkbit/s  vidoo  coding 
ajgcnLbm  and  ±e  low  bicrate  audio  aigonchm,  ’Jie  projec: 
’j/iil  concccffate  on  research  in  channels  for  mobile  hceo 
UonsmisrlotL  Nev  methods  like  HCPC  Codes  and  a  Scxibie 
exc.cange  berA'csr.  wurce  and  channel  data  rates  ’wl  be 
anaiysed,  as  well  as  combined  source  and  channel  coding 
.T.cmocs.  C«cnonscatcr  harewaxe  'vul  be  buiit  within  the 
CH'CT  mvircnmecc  insisting  of  muiti-processor  DSPs  and 
■'/ISIs.  Per  ‘he  UMTS  avironment  a  full  aansmission 
simuiauon  '*iU  be  done. 

Key  Issues 

Z  Service  dcliuiion  and  user  requircner.ts, 

2  Inilucice  of  nerworx  and  channel  charaetehsuc. 

Z  Suitable  video  and  audio  coding  aigonihms. 
a  Channel  error  proiecaon  for  video  and  audio. 

Z  Syr*em  controL 

C  Demonstrator  realisation  with  modem  DSP  and  VLSI 
rjruits. 


Achievements 

MAVT  has  idenuiled  possible  video  and  audio  services  for  a 
mobile  temunai,  and  the  input  video  fonnau  Ibr 

those  services.  A  reference  model  for  low  bicraie  video 
efldjp^  was  created,  and  a  urst  aigohthin  for  px  Skbit/s  video 
coding  was  produced. 

New  aigorithms  were  developed  that  optimise  low  bitrate 
video  and  audio  coding  in  terms  of  bitrate,  complexity  and 
transmiaaon  delay.  Some  are  based  on  current  standards 
(HD51,  MPEG,  JPEG)  and  are  suiuble  for  the  short  term 
devciopmcni  of  a  demonstrator.  Other  algorithms  use  with 
later  versions  usuig  advanced  coding  techniques  and  will 
conenbute  for  the  deunition  of  future  standards.  Rate 
Compatibic  punemred  Ccnvoiuuonai  (RCPC)  codes  and 
camoinca  source -enannei  coding  have  been  introauced  into 
the  video  coding  task. 

Furth^  achievements  are  expected  In  the  areas  of: 

a  Non  Cempaubiiity  of  Video  Cooing  ende-  UMTS 
0  Development  of  Video  fronc-end  Kareware 
3  Devciopmcni  of  Video  Cocec  Hardware 
a  Ccntrci  Dnver  Funcuens  for  a  Video  Codec 
C  Impicmenution  of  the  ’/ideo  and  Audio  Algorithms 
□  Plaubrm  Deveiopment 

Expected  Impact 

Projec:  results  -will  ccntr.bute  to  standardisation  activities 
within  ISO,  Cenr  ana  ETSl  Improvcnents  made  :o  exist¬ 
ing  coding  algorithms  could  inxluence  start dardisau on  oi  the 
cocopaublc  coaer  (recommendations  HD61,  MPEG,  JPEG). 

Results  will  be  useful  to  designers  and  manutacrurers  ot 
sffvices  and  leminais,  by  providing  basic  design  guidelines 
and  human  recommenGauons  for  mobile  civironmcnis.  In 
this  way,  they  may  acccicrate  'Jie  penetration  of  mobile 
handheld  terminais  in  the  market,  as  an  artracuve  form  of 
personal  communicauon. 
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Abstract 


The  main  technical  objectives  of  MAVT  are  the  development  of  robust  video  and  audio  cod¬ 
ing  algorithms  for  transmission  of  moving  (still)  video  and  associated  audio  in  DECT  and 
UMTS.  Due  to  a  variety  of  channel  impairments  encountered  in  case  of  a  wireless  mobile 
propagadon  medium  addidonal  countermeasures  have  to  be  undertaken  to  guarantee  the  target 
transmission  quality.  This  paper  includes  corresponding  error  control  strategies  under  Inves- 
tigadon  in  the  context  of  die  RACE  MAVT  projeca 


1.  Introduction 

A  new  challenging  field  of  research  is  the  area  of  very  low  bit  ."ate  video  source  coding  with 
data  rates  of  pxS  kb/s  (n=i..3)  in  connecdon  with  a  mobile  'wireless  transmission  such  as  in 
DECT  and  die  future  UMTS.  Corresponding  H.S61  aon-compadble  and  compadbie  source 
coding  algorithms  have  been  developed  in  the  context  of  the  MAVT  projeca  In  general  low 
bit  rate  source  coding  algorithms  are  very  sensidve  to  channel  errors  due  to  the  high  com¬ 
pression  factors.  F’orthermore,  a  target  nerwork  may  only  guarantee  a  spec'Iiic  average  trans¬ 
mission  quality  (nenvork  dependent),  which  will  not  suffice  in  the  consider  applicadon  (e.g, 
DECT).  Therefore,  an  addirionai  ser/ice  dependent  error  control  strategy  must  be  applied, 
which  should  consider  the  underlying  channel  characterisdcs  as  well  as  the  sensidvity  of  the 
source  against  channel  errors  or  error  events. 

Secdon  H  includes  some  aspect  related  to  the  nerwork  and  transmission  channel  characteris¬ 
dcs  in  case  of  the  target  networks,  with  special  emphasis  on  DECT.  An  efficient  channel 
coding  design  must  consider  the  characterisdcs  of  the  underlying  discrete  channel,  which 
dewnmines  the  error  process.  Results  obtained  through  a  descripdve  modelling  approach  in 
case  of  a  data  transmission  in  DECT  with  32  kb/s  are  presented. 

In  the  context  of  MAVT  two  source  cot^g  approaches  are  considered,  namely  a  H.261  non- 
compadble  hybrid  algorithm  and  H.261  related  algorithms  with  different  informadon  data 
rates.  Coiiesponding  forward  error  correcdon  strategies  are  presented  in  Section  m,  where 
a-oriori  knowledge  about  the  bit  sensidvity  of  the  source  codec  is  incorporated  in  the  design 
of  a  non-uniform  error  protecdon  scheme. 


n.  Channei  Characteristics 


A  general  dme* varying  multipath  channei  introduces  dme  and  fretiuency  dispersion  in  the 
transmitted,  whereby  two  interference  erfeca  can  be  described.  In  case  of  a  pure  dme  selec- 
dve  or  frequency  dispersive  propagadon  channel,  the  field  strength  of  the  received  envelope 
exhibits  extreme  variadons,  Le.,  signal  fading,  which  are  inversely  proportional  to  the  maxi¬ 
mum  Doppler  frequency  For  low  signal  levels,  Le.,  a  low  signal  to  noise  ratio,  this 
implies  error  bursts  in  case  of  a  data  transmission  due  to  the  channei  memory.  For  high 
SNRs  the  effeca  due  to  the  random  phase  predominates  yielding  an  irreducible  error  floor. 

A  pure  frequency  selective  or  time  dispersive  propagation  channei  is  characterized  by  a  fre¬ 
quency  dependent  aansfer  function,  where  die  variations  are  inversely  proportional  to  the 
underlying  delay  spread  t,.  Due  to  the  nonideal  specsal  characteristic,  die  transmitted  signal 
is  linearly  distoned,  which  implies  intersymbol  intenerence  (ISI)  in  case  of  a  data  trans¬ 
mission.  The  general  case  is  characterized  by  a  superposidon  of  the  above  wo  efreca. 

The  statistical  structure  of  the  resulting  error  process  is  completely  determined  by  the  under¬ 
lying  discrete  channei.  Relevant  satistical  parameters  can  be  detenmined  from  corresponding 
error  seauencss  either  by  direct  processing  (descriptive  modelling)  or  aom  a  pararaearized 
mathemadcai  mode:  (generadvc  modelling).  The  error  process  can  be  equivalently  described 
in  terms  of  successive  gaps  of  Icngdi  g,  where  a  gap  is  denned  as  a  suing  of  v-1  consecutive 
error  free  symbols  beween  nvo  error  symbols  and  having  a  length  equal  to  v.  Tne  gap  pro¬ 
cess  represent  a  realizadon  of  a  stochastic  process  and  therefore  it  can  be  described  by 
corresponding  satisacs  such  as  the  gap  density  and  cumulative  distribution,  whereby  in  case 
of  a  so  called  renewal  process.  Le.,  uncorreiated  successive  gap  lengths,  the  gap  process  is 
uniquely  dcrlned  by  me  single  error  gap  density  :(v)=?r(g=v)  or  disetbudon  F(v)=?r(gi  >v), 

V  veN. 

A  relevant  parameter  for  code  design  in  case  of  random  error  correction  is  the  biocic  emor 
probabiiicy  P(m,n)=?r(numbcr  or  errors=m,  block  of  lengm  n).  Kerc'witii  one  obtains  the 
resulting  error  rate  in  case  of  a  biocic  code  capable  of  correcting  t  erron  directiy.  In  case  of 
burs:  error  correction,  me  relevant  parameter  is  die  burst  error  probability  QG,n)=?r(bui3t 
lengm=l.  block  ox  lengtii  n),  where  a  burst  is  the  length  starting  from  the  first  error  to  the  last 
en'or  irrespective  of  the  sffucaire  in  berween.  For  bit  interleaving  the  relevant  parameter  is 
the  autocovariance  coefficient  p()c)=cov(e„eJ/var(e)  of  me  error  process.  The  interleaving 
degree  should  be  chosen  equal  to  the  value  of  ic  for  which  p()c)  is  zero  or  a  minimum.  Fur¬ 
ther  relevant  surisrics,  as  well  as  the  ones  discussed  above,  can  be  derived  directly  from  the 
corresponding  gap  process  and  are  presented  in  [1].  The  following  figures  represent  error  pro¬ 
files  evaluated  from  corresponding  error  sequences  in  case  of  a  DECT  transmission  link  and 
a  geneni  time-variant  multipath  channei  with  a  data  rate  of  32  kb/s.  The  propagation  channel 
is  chaiactenzed  by  the  classical  Doppicr  speemum  and  a  one  sided  exponendal  power  pronle. 


a 


b 


Fig.  2  Cumulative  block  emor  dismbudon  P(>m,n) 
(fp^,=2.5;Z5  Hz;  ■c.=0  ns)  a  SNR=20  dB.  b  SiNR=30  dB 


Fig.  3  Autocovariance  coefficient  p(ic) 

(fo^=2.5a5  Hz;  SNR=30  dB)  a  ^,=0  ns.  b  t  =100  ns. 


HL  Combined  Source-Channei  Coding 
A.  Source  coding 

There  are  two  video  source  coding  approaches  which  are  followed  in  the  context  of  MAVT, 
namely  a  E261  noncompadble  hybrid  codec  and  several  IiL261/MPEG  rel^  algorithms  P]. 
The  considered  source  data  rates  in  case  of  DECT  are  8, 16  and  24  kb/s  for  the  noncompat- 
iblc  and  16  and  24  kb/s  for  the  compadble  code.  The  frame  rate  equals  6.25  Hz,  while  the 
spadai  resolurion  is  QCIF  in  both  cases.  The  associated  CEL?  speech  codec  is  chaiacwrized 
by  a  total  data  rate  of  8  kb/s  including  channel  coding.  The  compound  transmission  in  DECT 
includes  addidonal  control  and  sync.hronizarion  informadon  and  will  be  accomplished  by 
using  one  slot  of  the  TDMA  frame,  Le.,  with  a  gross  data  rate  of  32  kb/s.  Bodi  coding 
approaches  will  be  applied  in  case  of  narrowband  UMTS,  while  in  the  broadband  case  the 
H.261  compadble  scheme  alone  will  be  considered.  In  this  applicadon  higher  data  rates  (>32 
kb/s)  are  allowed. 


B.  Error  control  strategies 

Due  to  compadbility  resancrion  a  uniform  cttot  protecdon  (block  codes)  for  the  informadon 
pan  adapted  to  the  corresponding  applicadon  will  be  toilowee  in  case  of  the  H.261  compat¬ 
ible  scheme.  Key  aspects  are  the  selecdon  of  an  appropriate  frame  alignment  signal  (F.'^S) 
inclusive  error  protecdon  and  the  necessary  enor  protecdon  of  die  bit  .“ate  allocadon  signal 
(BAS)  in  case  of  the  targe:  wireless  mobile  cransmission.  In  case  of  the  noncompadbie  video 
source  codec  an  unequal  random  error  protecdon  scheme  'will  be  adopted.  The  design  of  the 
proper  individual  channel  codes  considers  a-priori  knowledge  about  the  sensidviy  of  the 
souree  informadon  against  channel  errors.  Reference  to  ng-are  4  reveals,  that  the  individual 
bits  i  at  die  output  of  die  source  encoder  ex.hibit  a  significant  diftercncc  with  respect  to  their 
segmental  signal  to  noise  rado  (SEGSNR)  in  case  of  single  independent  channel  errors. 


a 


b 


Fig,  4  Bit  sensiriviry  of  the  H.261  noncompadble  hybrid  video 
codec  with  16  kb/s.  a  Luminance,  b  Chrominance 


This  fact  suggests  the  application  of  different  ezror  protection  levels,  which  can  be  realized 
efficiently  through  rate  compatible  punctured  convolutional  (RCPC)  codes  [3].  A  further 
approach  which  is  under  investigation  is  a  concatenated  scheme,  composed  of  an  outer  block 
codec  and  an  inner  RCPC  codec.  ^  both  cases  a  convolutional  interleaver  will  be  applied  for 
randomizing  the  underlying  error  events,  in  general  the  optimization  of  the  proper  enor 
correction  scheme  represents  a  compromise  between  avoidable  redundancy,  resulting  delay 
and  computational  burden.  On  the  receiver  side  several  strategies  for  improving  the  system 
pexfotinance  can  be  applied.  Current  investigation  are  concerned  with  soft-decision  video 
decoding  and  efficient  error  concealment  methods. 
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FicturcWlndow  Desktop  Video  Conferencing 


2.  What  is  PictureWindow? 

BBN’s  PictureWindow  system  brings  multiparty,  wide-area  video  conferences  directly 
onto  your  workstation  screen  with  minimal  additional  hardware.  PictureWindow  gives  you 
personal  video  conferencing  capability  through  the  use  of  BBN  software,  Sun’s  inexpensive 
VideoPix  frame-capture  board,  and  a  video  camera  on  your  existing  color  SPARCstation. 

PictureWindow  compresses  and  decompresses  video  entirely  in  software,  transmits  it 
using  standard  IP  protocols,  and  displays  it  in  multiple  windows  under  OpenWindows™ 
or  the  X  Window  System.  It  operates  with  equal  ease  between  offices  and  between 
continents  over  Internet  Protocol  (IP)  based  wide-area  networks,  and  it  can  be  used  in 
either  point-to-point  or  multicast  modes. 

What  PictureWindow  Does 

In  PictureWindow,  video  from  each  conferee  appears  in  a  separate  workstation  window. 
ParticipanLs  may  join  or  leave  the  conference  at  any  time;  new  windows  appear  as  partici¬ 
pants  join  and  disappear  when  they  leave.  A  user  can  only  participate  in  one  video  confer¬ 
ence  at  a  time,  but  the  number  of  participants  in  the  conference  is  limited  only  by  worksta¬ 
tion  and  netw'ork  speed. 

Initiating  or  joining  a  conference  is  simple:  you  run  the  PictureWindow  program  and 
press  the  Connect ...  button.  PictureWindow  will  display  your  personal  video  conference 
address  book.  Select  a  person  to  confer  with  and  confirm  the  connection;  if  the  person 
you  have  selected  accepts  your  call,  video  images  from  their  workstation  will  appear  within 
a  few*  seconds  and  your  image  will  automatically  be  displayed  at  their  location.  To  add  more 
conferees,  just  press  Connect, ..  again.  You  can  terminate  a  single  connection  by  pressing  the 
Hang  up  button  in  its  video  window.  You  can  terminate  the  entire  conference  by  clicking 
on  the  Hang  up  all  button  in  the  main  PictureWindow  window. 

PictureWindow  video  windows  measure  320x240  pixels  with  16  levels  of  gray.  Refresh 
rate  depends  upon  system  and  network  load,  but  is  tv^^ically  between  3  and  6  frames  per 
second.  A  SPARCstation^^  1,  1+,  2,  IPC,  or  IPX  will  support  video  conferences  with  six  to 
eight  participants.  PictureWindow  easily  coexists  with  other  applications  on  the  worksta¬ 
tion,  so  users  can  confer  over  documents  using  other  tools  while  participating  in  a  video 
conference. 

PictureWindow  sends  compressed  video  in  UDP/IP  datagrams  and  functions  in  both  local 
and  wide-area  network  environments.  The  actual  network  bandwidth  used  by  any  one  con¬ 
feree  depends  on  the  amount  of  motion  in  the  supplied  video,  and  the  image  quality  desired 
by  the  viewers.  In  two-way  conferences,  each  conferee  can  selectively  adjust  the  quality  and 
compression  parameters  for  the  image  they  are  viewing.  PictureWindow  functions  best 
v/hen  network  paths  with  at  least  256  kilobits/second  are  available.  Nevertheless,  network 
paths  as  slow  as  56  kilobits/second  can  be  used  by  decreasing  the  frame  rate  and  increasing 
the  acceptable  image  error. 


User’s  Manual 


Picture  Window  System  Requirements 

PictureWindow  currently  runs  on  Sun  Microsystems®  SPARCstations  or  fully  compatible 
workstations  equipped  with  8-  or  24-bit  color  frame  buffers.  It  requires  a  local  X  server 
with  the  MIT  shared-memory  extension,  such  as  MIT  X11R5,  OpenWindows  2.0,  or 
OpenWindows  3.0.  Transmit  capability  requires  the  installation  of  the  Sun  VideoPix  card; 
however,  receive-only  copies  of  the  software  are  available  that  do  not  require  any  additional 
hardware  to  be  added  to  your  Sun  SPARCstation. 

Video  input  can  come  from  any  color  or  black-and-white  television  source,  such  as  a 
camera,  camcorder,  or  VCR.  Available  video  input  formats  are  NTSC  and  PAL  video,  and 
they  can  be  supplied  using  composite  or  S-Video  input  connectors.  Sources  with  lower 
background  noise  will  yield  better  video  compression  ratios. 

The  required  hardware  to  run  PictureWindow  is  as  follows: 

•  Sun  SPARCstation  1,  1+,  2,  10,  IPC,  or  IPX  workstation 

•  8-bit  or  24-bii  color  or  grayscale  frame  buffer 

•  16  Meg  main  memory  (minimum) 

•  Sun  VideoPix  card 

•  Black-and-white  or  color,  NTSC  or  S- Video  camera 

•  Ethernet  with  TCP/IP  protocol  stack  running  (standard  Sun  configuration) 

•  Access  to  CD-ROM  drive  to  load  VideoPix  softw^are  driver 

•  Access  to  floppy  disk  drive  to  load  PictureWindow  software  (standard  on  all  above 
workstations). 

The  operating  system  softw^are  requirements  are: 

•  SunOS'*”^  4.1.1  or  later ^ 

•  Sun  VideoPix  derice  driver 
(i.e.,  system  reports: 

vfcO  at  SBus  slot  1  0x0  on  booting) 

•  IPCSHMEM  option  enabled  (Note:  the  GENERIC  kernel  configuration  that  came  with 
your  Sun  has  this  option  enabled,  but  the  GENERIC^SMALL  kernel  configuration  does 
not). 

You  also  need  to  run  an  X  Window  System-compatible  windowing  environment.  The 
requirements  for  this  software  are: 

•  X  Window  System  compatibility 

•  An  X  Window  Server  that  exports  an  8-bit  PseudoColor  visual 

•  The  MIT-SHM  extension  that  permits  memory-mapped  X  windows, 

OpenWindows  2.0,  OpenWindows  3.0,  XI 1  Release  4,  and  XU  Release  5  will  all  satisfy 

the  requirements  for  the  windowing  software  when  run  on  8-bit  or  24-bit  color  displays. 

^At  present,  Picture  Window  is  not  supponed  under  Solaris^versions  2.0  or  later. 


5 


